PD-82 — Spécification canonique contractuelle¶

1. Objectif¶

La User Story PD-82 définit le mécanisme contractuel de contrôle 2 validations requises sur 2 possibles (2-of-2) pour autoriser l'activation d'une délégation cryptographique PRE sur un coffre mineur.

Le système DOIT garantir qu'aucune activation PRE ne peut être réalisée de manière unilatérale, implicite ou rétroactive, et DOIT produire une trace probatoire vérifiable indépendamment.

2. Périmètre / Hors périmètre¶

Périmètre¶

• Activation PRE impliquant un coffre mineur.
• Cas de réquisition judiciaire.
• Cas d'obstruction parentale (initiation possible par l'autorité compétente).
• Contexte B2C mineurs sous supervision encadrée.
• Portail autorité Phase 1 (2026-2027) avec autorité pré-enregistrée et authentification forte.
• Application d'un TTL strict de 7 jours calendaires pour la complétion de la seconde validation.
• Révocation possible avant activation complète par le validateur d'origine uniquement.

Hors périmètre¶

• Partages standards entre adultes.
• Délégations internes B2B.
• Opérations purement informatives sans impact sur les clés.
• Intégration API machine-to-machine judiciaire (Phase 2 future).
• Définition interne de l'algorithme cryptographique PRE (couvert par PD-41).
• Implémentation technique des mécanismes HSM/certificats (couvert par PD-37).

3. Définitions¶

4. Invariants (non négociables)¶

5. Flux nominaux¶

Flux N1 — Validation parent puis autorité¶

1. État initial: PENDING_BOTH.
2. Parent valide explicitement et signe: état PENDING_AUTHORITY.
3. Autorité compétente valide explicitement et signe avant TTL 7 jours.
4. Système vérifie les deux validations distinctes, valides, non révoquées, non expirées.
5. Système déclenche activatePRE(delegationId).
6. État final: ACTIVATED (terminal).

Flux N2 — Validation autorité puis parent¶

1. État initial: PENDING_BOTH.
2. Autorité valide explicitement et signe: état PENDING_PARENT.
3. Parent valide explicitement et signe avant TTL 7 jours.
4. Contrôles identiques au Flux N1.
5. Activation PRE puis état final ACTIVATED.

Flux N3 — Traçabilité probatoire complète¶

1. Chaque transition produit un événement append-only horodaté.
2. L'événement d'activation référence explicitement les identifiants des deux validations.
3. Le dossier de preuve est exportable dans un format probatoire (RFC 3161 ou équivalent).
4. Un audit externe peut reconstruire l'ordre exact des événements.

5bis. Diagrammes¶

Diagramme d'états — Cycle de vie de la délégation PRE 2-of-2¶

États terminaux : ACTIVATED, REJECTED, EXPIRED — aucune transition sortante (INV-82-04, INV-82-11, CA-82-10).

stateDiagram-v2
    [*] --> PENDING_BOTH : Création demande PRE

    PENDING_BOTH --> PENDING_AUTHORITY : Parent valide + signe [INV-82-09]
    PENDING_BOTH --> PENDING_PARENT : Autorité valide + signe [INV-82-09]
    PENDING_BOTH --> REJECTED : Révocation par initiateur [INV-82-04]
    PENDING_BOTH --> EXPIRED : TTL 7j dépassé [INV-82-03]

    PENDING_AUTHORITY --> ACTIVATED : Autorité valide avant TTL [INV-82-01, INV-82-08]
    PENDING_AUTHORITY --> REJECTED : Révocation par auteur validation [INV-82-04]
    PENDING_AUTHORITY --> EXPIRED : TTL 7j dépassé [INV-82-03]

    PENDING_PARENT --> ACTIVATED : Parent valide avant TTL [INV-82-01, INV-82-08]
    PENDING_PARENT --> REJECTED : Révocation par auteur validation [INV-82-04]
    PENDING_PARENT --> EXPIRED : TTL 7j dépassé [INV-82-03]

    ACTIVATED --> [*]
    REJECTED --> [*]
    EXPIRED --> [*]

    note right of ACTIVATED
        État terminal — activatePRE(delegationId)
        déclenché une seule fois [INV-82-11]
    end note

    note right of REJECTED
        État terminal — consentement
        retiré, aucune activation possible
    end note

    note right of EXPIRED
        État terminal — nouveau
        processus requis [INV-82-02]
    end note

Diagramme de séquence — Flux N1 (Parent puis Autorité)¶

Illustre le flux nominal avec vérification cryptographique et journal append-only (INV-82-06, INV-82-07, INV-82-09, INV-82-10, INV-82-12).

sequenceDiagram
    autonumber
    participant P as Parent
    participant API as PD-82 Service
    participant SIG as Vérification Signatures<br/>(X.509/eIDAS)
    participant PRE as PD-41 PRE Module
    participant LOG as PD-31 Journal<br/>Append-only

    P->>API: Initier demande PRE (coffre mineur)
    API->>LOG: Événement CREATED [INV-82-12]
    API-->>P: État PENDING_BOTH

    P->>API: Validation parent (signature + certificat)
    API->>SIG: Vérifier signature + identité [INV-82-09, INV-82-10]
    SIG-->>API: Signature valide, identité opposable
    API->>LOG: Événement VALIDATION_PARENT (timestamp probatoire) [INV-82-06, INV-82-07]
    API-->>P: État PENDING_AUTHORITY

    participant A as Autorité compétente
    Note over A,API: Autorité résolue via registre interne [INV-82-05]

    A->>API: Validation autorité (signature + certificat)
    API->>SIG: Vérifier signature + identité [INV-82-09, INV-82-10]
    SIG-->>API: Signature valide, identité opposable

    API->>API: Vérifier 2-of-2 : deux validations<br/>distinctes, valides, non révoquées,<br/>TTL < 7j [INV-82-01, INV-82-03]
    API->>PRE: activatePRE(delegationId) [INV-82-11]
    PRE-->>API: Activation confirmée
    API->>LOG: Événement ACTIVATED (réf. 2 validations) [INV-82-12]
    API-->>A: État ACTIVATED (terminal)

Diagramme de séquence — Révocation avant activation¶

Illustre le flux de révocation par l'auteur de la validation (INV-82-04, ERR-82-03).

sequenceDiagram
    autonumber
    participant P as Parent
    participant API as PD-82 Service
    participant LOG as PD-31 Journal<br/>Append-only

    Note over API: État PENDING_AUTHORITY<br/>(validation parent existante)

    P->>API: Révoquer ma validation
    API->>API: Vérifier auteur = signataire<br/>de la validation [INV-82-04]
    API->>LOG: Événement REVOKED (timestamp) [INV-82-12]
    API-->>P: État REJECTED (terminal)

    Note over API: Toute tentative ultérieure<br/>d'activation est refusée [CA-82-10]

6. Cas d'erreur¶

7. Critères d'acceptation (testables)¶

8. Scénarios de test (Given / When / Then)¶

ST-82-01 — Blocage avec une seule validation¶

Given une demande PRE en état PENDING_BOTH
When le parent valide correctement
Then l'état devient PENDING_AUTHORITY
And aucun appel activatePRE(delegationId) n'est effectué

ST-82-02 — Activation après double validation parent→autorité¶

Given une demande PRE en état PENDING_AUTHORITY avec validation parent valide
When l'autorité valide dans le délai de 7 jours avec signature valide
Then l'état devient ACTIVATED
And activatePRE(delegationId) est appelé une seule fois

ST-82-03 — Activation après double validation autorité→parent¶

Given une demande PRE en état PENDING_PARENT avec validation autorité valide
When le parent valide dans le délai de 7 jours avec signature valide
Then l'état devient ACTIVATED
And activatePRE(delegationId) est appelé une seule fois

ST-82-04 — Expiration TTL¶

Given une demande PRE avec une première validation horodatée T0
When la seconde validation arrive après T0 + 7 jours
Then l'état est EXPIRED
And activatePRE(delegationId) n'est jamais appelé

ST-82-05 — Révocation valide avant activation¶

Given une demande PRE en état PENDING_AUTHORITY avec validation parent
When le parent révoque explicitement sa validation avant la seconde validation
Then l'état devient REJECTED
And toute activation ultérieure sur ce processus est refusée

ST-82-06 — Révocation invalide par tiers¶

Given une demande PRE avec validation parent existante
When l'autorité tente de révoquer la validation du parent
Then la révocation est rejetée
And l'état métier reste inchangé

ST-82-07 — Signature invalide¶

Given une demande PRE en attente d'une validation
When une validation est soumise avec signature non vérifiable
Then la validation est rejetée
And un événement de rejet cryptographique est journalisé

ST-82-08 — Autorité imposée par registre interne¶

Given une demande PRE initiée côté parent
When le parent fournit un identifiant d'autorité arbitraire
Then la sélection est refusée
And l'autorité est uniquement résolue via le registre interne habilité

ST-82-09 — Intégrité append-only¶

Given une chronologie d'événements de validation déjà enregistrée
When une opération tente de modifier ou supprimer un événement passé
Then l'opération est refusée
And un événement de tentative d'altération est ajouté au journal

ST-82-10 — Irréversibilité des états terminaux¶

Given une demande PRE en état ACTIVATED
When une requête de retour en état PENDING est soumise
Then la requête est rejetée
And l'état reste ACTIVATED

9. Hypothèses explicites¶

10. Points à clarifier¶

Références finales¶

• Epic : PD-189 — CRYPTO
• JIRA : PD-82
• Repos concernés : ProbatioVault-backend
• Documents associés : PD-41, PD-31, PD-240, PD-37