spec 3.1 : le bloc d'identité entre dans les champs engagés

[desiorac]

Le défaut

Jusqu'à 3.0 inclus, agent_identity, agent_identity_verified, did_resolution_status et identity_consistent étaient servis dans les réponses publiques (§9) et engagés nulle part : hors racine Merkle, donc hors hashes.chain, hors signature Ed25519, donc hors jeton RFC 3161 et hors entrée Rekor.

Mesuré par exécution sur une preuve 3.0 : passer agent_identity_verified de false à true et agent_identity de did:web:evil.example à did:web:trust.arkforge.tech laisse la vérification d'intégrité à true et le chain hash inchangé au bit près. Tout lecteur qui prenait agent_identity_verified pour une preuve prenait la parole de l'émetteur.

Ce que fait 3.1

• Les quatre champs deviennent des champs engagés, inconditionnellement : une identité absente est engagée à null. Les engager seulement quand ils sont présents laisserait un émetteur les omettre et un vérificateur sans engagement à refuser.
• Leurs nonces sont publiés dans la preuve, sous disclosed. Un engagement à nonce secret est non falsifiable mais illisible ; ces quatre valeurs doivent rester lisibles par un tiers, donc le masquage est abandonné sur elles et sur aucune autre.
• agent_identity_verified vaut true ou null, jamais false : une seule normalisation à la source, pour que la valeur engagée et la valeur servie ne puissent pas diverger.
• identity_consistent fait partie du lot : c'est un jugement sur l'identité. Engager ses trois voisins en le laissant dehors reconstruirait le même trou un champ plus à gauche.

Ce que ça établit, et ce que ça n'établit pas

Ça rend l'affirmation d'identité non répudiable : l'émetteur s'y est engagé avant l'ancrage et ne peut plus se dédire. Ça ne rend pas le binding lui-même vérifiable par un tiers : aucun artefact public ne prouve que le challenge-response Ed25519 a eu lieu. C'est écrit tel quel dans la §2.

Une preuve en spec_version inférieur à "3.1" ne porte aucune identité ancrée, et un vérificateur ne doit pas la traiter comme une preuve d'identité.

Mesure

• Vecteurs 13 et 14 générés par une réimplémentation indépendante (hashlib nu), puis recoupés avec l'implémentation Trust Layer. Les deux devaient concorder avant écriture.
• check_consistency.py étendu : il vérifie que les nonces publiés ouvrent bien leurs engagements, et non seulement que la racine tombe juste.
• ALL CHECKS PASSED, 14 vecteurs, compte aligné avec le README.

Les preuves en 3.0 et antérieures gardent leur algorithme et restent vérifiables.

⚠️ À merger avant le déploiement de Trust Layer 1.9.0 : le gate 4 du déploiement fait tourner la suite trust-layer, qui lit test-vectors.json depuis le clone proof-spec de VPS1.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CzXFq94XGK7vcDgoSRsPFp