PD-82 — Expression de besoin¶

1. Contexte¶

Dans le cadre des cas d'usage mineurs décrits dans l'architecture ProbatioVault (supervision parentale et accès judiciaire), certaines opérations sensibles ne peuvent être déclenchées par une seule entité.

En particulier, l'activation d'un mécanisme de délégation cryptographique (PRE – Proxy Re-Encryption) concernant les données d'un mineur doit être soumise à un double contrôle indépendant : - Le représentant légal (parent) - Une autorité compétente (juge, magistrat, autorité administrative habilitée)

Le module PRE est implémenté par PD-41. Cette story (PD-82) définit le mécanisme de déclenchement 2-of-2 qui autorise l'activation PRE.

2. Besoin utilisateur¶

En tant que plateforme ProbatioVault, Je veux un mécanisme de validation double (parent + autorité), Afin de garantir qu'aucune activation de délégation cryptographique irréversible ne puisse être réalisée unilatéralement.

Schéma logique¶

✅ Validation 1 : Parent
✅ Validation 2 : Autorité compétente
➜ Activation PRE effective

Le système se comporte comme un mécanisme de type 2 validations requises sur 2 possibles.

3. Périmètre fonctionnel¶

Inclus¶

• Opérations d'activation PRE impliquant un coffre mineur
• Cas de réquisition judiciaire
• Situations d'obstruction parentale (l'autorité peut initier)
• Contextes B2C mineurs relevant de la supervision encadrée

Exclus¶

• Partages standards entre adultes
• Délégations internes B2B
• Opérations purement informatives sans impact sur les clés

4. Contraintes et décisions¶

4.1 TTL des validations¶

• Durée de validité : 7 jours
• Une validation expire si l'autre partie n'a pas validé dans ce délai
• Après expiration, le processus doit être relancé

4.2 Accès autorité compétente¶

Phase 1 (2026–2027) — Portail dédié : - Authentification forte obligatoire (certificat qualifié, eIDAS, ou compte validé manuellement) - Autorité pré-enregistrée par ProbatioVault - Le parent ne choisit jamais l'autorité - Demande routée vers autorité compétente via registre interne - Journalisation complète

Phase 2 (future, si traction judiciaire) : - API machine-to-machine avec systèmes judiciaires - Identité garantie par infrastructure de l'autorité

4.3 Révocabilité¶

• Oui : Une validation peut être révoquée avant activation complète
• Seul le validateur original peut révoquer sa propre validation
• La révocation annule le processus (retour à l'état initial)

4.4 Dépendance PRE¶

• Le module PRE (PD-41) existe déjà
• PD-82 définit le déclencheur 2-of-2 qui autorise l'activation PRE
• Interface : activatePRE(delegationId) appelée uniquement après validation complète

5. Résultat attendu¶

Le système doit : 1. Identifier distinctement les deux entités habilitées (parent + autorité) 2. Attendre explicitement les deux validations 3. Empêcher toute activation partielle 4. Garantir l'immutabilité de l'état intermédiaire (append-only) 5. Produire une trace probatoire complète 6. Permettre la vérification indépendante a posteriori

6. Invariants fonctionnels (NON NÉGOCIABLES)¶

7. États fonctionnels¶

PENDING_BOTH ──┬──> PENDING_AUTHORITY (parent a validé)
               │
               └──> PENDING_PARENT (autorité a validé)
                         │
                         ├──> ACTIVATED (les deux ont validé)
                         │
                         ├──> REJECTED (révocation explicite)
                         │
                         └──> EXPIRED (TTL 7j dépassé)

Transitions autorisées : - PENDING_BOTH → PENDING_AUTHORITY (parent valide) - PENDING_BOTH → PENDING_PARENT (autorité valide) - PENDING_AUTHORITY → ACTIVATED (autorité valide) - PENDING_PARENT → ACTIVATED (parent valide) - PENDING_* → REJECTED (révocation) - PENDING_* → EXPIRED (TTL dépassé)

Transitions interdites : - ACTIVATED → (tout autre état) — irréversible - REJECTED → (tout autre état) — terminal - EXPIRED → (tout autre état) — terminal

8. Contraintes techniques¶

Sécurité¶

• Validations cryptographiquement authentifiées (signature)
• Identités non contestables (certificat X.509 ou signature eIDAS)
• Aucune clé PRE activée avant validation complète

Probatoire¶

• Chaque validation journalisée dans le registre append-only (PD-31)
• Événement d'activation rattachable aux deux validations
• Preuve exportable indépendamment (format RFC 3161 ou équivalent)

Juridique¶

• Respect du cadre RGPD (mineurs)
• Compatibilité avec exigences judiciaires françaises
• Capacité à produire un dossier probatoire complet pour tribunal

9. Résultats inacceptables¶

• ❌ Activation PRE avec une seule validation
• ❌ Validation rétroactive (antidatage)
• ❌ Possibilité pour ProbatioVault d'activer sans les deux parties
• ❌ Absence de preuve exportable
• ❌ Modification d'un état après activation (immutabilité violée)
• ❌ Auto-approbation par timeout (validation implicite)

10. Critères d'acceptation fonctionnels¶

11. Tensions structurantes (à préserver)¶

Ces tensions ne doivent pas être résolues prématurément.

12. Dépendances¶

13. Synthèse¶

PD-82 introduit un mécanisme de contrôle à double signature logique pour les opérations sensibles impliquant un mineur.

Ce mécanisme doit : - Protéger le mineur (pas d'accès abusif) - Protéger le parent (pas de pression unilatérale) - Protéger l'autorité (décision tracée) - Protéger la plateforme (neutralité probatoire) - Préserver la valeur probatoire du système

Il s'agit d'un verrou cryptographique et juridique structurant de l'EPIC PD-189 — CRYPTO.

Document rédigé le 2026-02-17 Workflow de gouvernance ProbatioVault