PD-287 — Clarifications PO (2026-04-19)¶

Quel est le problème ou le besoin utilisateur ?¶

Permettre à un utilisateur de déléguer temporairement un droit de lecture probatoire à un tiers externe (avocat, forces de l'ordre), sans imposer la création d'un compte complet, tout en conservant : - l'intégrité et la valeur probatoire de la preuve - le contrôle d'accès (révocation, durée, périmètre) - l'absence de transfert de propriété ou de co-détention - la traçabilité complète des accès

Le partage n'est pas un envoi de document mais une délégation d'accès cryptographique contrôlée. Aligné avec le modèle PRE : transformation d'accès sans déchiffrement, journalisation + preuve composite.

Quels sont les critères de succès ?¶

UX / Produit : - Un lien de partage est généré en quelques secondes - Le destinataire peut accéder à la preuve sans création de compte persistante - L'accès est possible via une identité invitée éphémère (créée à la volée)

Sécurité / Crypto (CRITIQUE) : - Aucun document dupliqué côté serveur (respect strict WORM) - Aucune clé de chiffrement document exposée ou persistée hors modèle PRE - L'accès repose sur une délégation PRE vers une identité éphémère - Le serveur reste aveugle (zero-knowledge conservé)

Accès & consultation : - Le destinataire peut consulter le document + la preuve complète (hash, Merkle, TSA, blockchain) - Accès strictement en lecture seule

Export : - Possibilité d'exporter une preuve composite vérifiable - La preuve exportée est équivalente du point de vue probatoire et vérifiable indépendamment du système - Aucun export ne nécessite une rupture du modèle zero-knowledge

Auditabilité : - Chaque accès est journalisé (append-only), signé, ancré (via Merkle / blockchain) - Possibilité de prouver : qui a accédé, quand, à quelle preuve

Y a-t-il des contraintes connues ?¶

Contraintes cryptographiques fondamentales : - Modèle zero-knowledge strictement préservé : aucune donnée en clair côté serveur, aucune clé document exposée - Partage repose exclusivement sur PRE (transformation d'enveloppe de clé) - Toute délégation est signée, journalisée, ancrée dans la preuve composite

Identité du destinataire : - "Sans compte" = absence de compte persistant, MAIS présence d'une identité cryptographique éphémère - Création à la volée : paire de clés, certificat temporaire (PKI / Keycloak ou équivalent) - Authentification légère (ex : OTP email) - Association identité <-> accès

Contrôle d'accès : - Accès limité dans le temps (TTL) - Révocation possible à tout moment (invalide les accès futurs) - Aucune révocation rétroactive sur contenu déjà consulté

Intégrité & stockage : - Aucun nouveau fichier créé : un seul document WORM, une seule empreinte - Seules les enveloppes d'accès sont modifiées

Traçabilité & conformité : - Tracking des accès obligatoire : timestamp, identité (même éphémère), métadonnées techniques - Conformité RGPD : base légale = preuve / intérêt légitime, minimisation des données

Quelles sont les priorités (must-have vs nice-to-have) ?¶

Must-have : - Délégation PRE vers identité éphémère - Identité cryptographique éphémère + OTP email - Consultation preuve complète (document + éléments cryptographiques) - Respect strict zero-knowledge et WORM - TTL + révocation - Traçabilité complète des accès (journal + ancrage)

Nice-to-have : - Export preuve composite vérifiable - Notification au propriétaire quand le lien est consulté