Résumé

  • Publiée le 5 septembre, la révision 01 du projet individuel Testimony Record corrige une phrase trop générale sur huit systèmes, spécifie le calcul du condensat et ajoute un état honnête des implémentations.
  • Les niveaux TR-1 à TR-4 couvrent successivement la forme du registre, l’explication des croyances, le contrôle des actes et l’intégrité vérifiable ; un émetteur qui déclare acts:false peut toutefois satisfaire TR-3 sans acte à contrôler.
  • Le texte distingue désormais les vérifications décidables à partir du registre des attestations que le lecteur doit encore croire, par exemple l’origine d’un niveau de risque ou de l’identité d’un approbateur.
  • Un horodatage RFC 3161 lie une empreinte à une date et à un tiers. Il ne prouve ni la véracité, ni l’exhaustivité, ni l’unicité du témoignage.
  • Toute utilisation en achat, audit ou conformité devrait exiger une matrice indiquant périmètre, résultat de chaque niveau, contrôles vérifiés, contrôles attestés, schéma d’intégrité et identité du validateur.

Un texte sur la preuve commence par se corriger

L’avis de publication dit seulement qu’un Internet-Draft de 18 pages a été rendu disponible le 5 septembre. La fiche Datatracker fixe le statut : projet individuel actif, sans flux RFC, sans Area Director responsable, sans position formelle dans le processus et sans approbation de l’IETF. La mention « Informational » exprime une destination souhaitée, pas un résultat institutionnel.

La différence entre les deux versions est substantielle. Le texte -00 affirmait qu’aucun des huit systèmes examinés ne conservait l’identité de la personne ayant approuvé un acte. Le texte -01 reconnaît que l’étude ne soutenait pas cette phrase. Parmi cinq systèmes pertinents qui n’étaient pas ceux de l’auteur, quatre avaient reçu le verdict « absent » et un cinquième « indéterminé ». Les trois autres comprenaient l’implémentation de référence de l’auteur.

Ce retrait applique la logique du format à son propre dossier. L’absence observée, l’impossibilité de trancher et une capacité présente dans le produit de celui qui mesure ne forment pas un même fait. Les fusionner aurait transformé un relevé limité en verdict universel.

Le diff officiel montre une réparation plus technique. La première version demandait un condensat sans indiquer l’algorithme, la sérialisation ni l’ordre. Le validateur de référence pouvait accepter une valeur déclarée sans la recalculer, tandis que deux chemins d’implémentation produisaient des octets différents. « Verifiable » était donc un nom plus fort que la propriété disponible au lecteur.

La révision 01 impose SHA-256 sur une liste ordonnée d’entrées, un JSON compact, un tri des membres par point de code Unicode, l’exclusion des annotations commençant par un trait bas, l’encodage UTF-8, des séparateurs LF précis et des bornes numériques. Le validateur recalcule la valeur. Deux lecteurs peuvent enfin départager leur désaccord à partir de la règle publiée.

L’échelle cumule des propriétés indépendantes

TR-1 vérifie que la séquence est lisible, homogène en version, composée de types connus, munie d’identifiants uniques et ordonnée par temps d’écriture. TR-2 exige que chaque croyance nomme ses éléments de preuve, y compris par un tableau vide qui avoue l’absence de fondement, et que les branches contradictoires restent visibles avec toute résolution ultérieure.

TR-3 concerne les actes ayant un effet externe. La classe de risque doit être attribuée à une source extérieure à la sortie du modèle. Un refus ne peut pas coexister avec executed:true. Un acte à haut risque exécuté doit renvoyer à une approbation humaine, à une source d’identité distincte du texte du modèle et à un approbateur qui n’est pas l’auteur de la proposition.

TR-4 contrôle l’intégrité du registre : présence des entrées couvertes, recalcul du condensat et, pour une ancre externe, correspondance entre l’empreinte signée et celle qui est annoncée. Chaque étape a un intérêt. Elles ne mesurent pas la même chose.

La version 0.2 introduit donc un champ scope. Un composant qui n’exécute ni ne filtre d’acte peut déclarer acts:false. S’il ne contient aucune décision, il satisfait TR-3 par absence d’acte à contrôler, puis peut atteindre TR-4 grâce à une bonne intégrité. Le projet recommande de dire « TR-4, registre seulement ». Supprimer le complément ferait croire qu’un contrôle d’action a été éprouvé.

Il serait absurde d’exclure ces composants. Un observateur ou une mémoire peut avoir besoin d’un historique très robuste sans posséder de pouvoir d’exécution. Le problème naît lorsque son bon registre sert d’attestation pour une chaîne d’action qui se déroule dans un connecteur, un hôte ou un service voisin hors périmètre.

Le périmètre reste une déclaration

Le validateur croit le champ scope. Si un émetteur prétend ne pas agir mais écrit une décision, la contradiction est détectable dès TR-1. S’il omet simplement les actes effectués ailleurs, le fichier ne révèle pas ce manque. Une organisation qui achète le système doit donc cartographier le vrai bord d’exécution : quel processus propose, autorise et déclenche l’effet ; quels chemins contournent l’émetteur ; quelle preuve indépendante rattache ces chemins au périmètre déclaré.

Le dépôt public de Machine Testimony rend accessibles la spécification, les validateurs, les adaptateurs et le corpus de conformité. C’est du code observable, donc davantage qu’une promesse. C’est aussi une source contrôlée par l’auteur. La nouvelle section d’implémentation dit clairement que toutes les implémentations connues sont les siennes. Deux validateurs écrits séparément peuvent déceler une ambiguïté ; ils ne représentent pas deux interprétations indépendantes.

Le répertoire du recensement fixe les versions examinées, exige des traces pour un verdict d’absence et publie les conflits d’intérêts. Il consigne même les défauts trouvés dans le travail de l’auteur. Cette discipline ne transforme pas l’exercice en audit indépendant : le même auteur définit l’instrument, produit la référence et mène l’examen.

« Vérifié » et « attesté » partagent le même numéro

Une vérification au sens du nouveau texte peut être tranchée dans le registre. L’entrée de preuve citée existe ou non. Les deux branches d’un conflit sont conservées ou non. Un refus est, ou n’est pas, présenté comme exécuté. Le condensat correspond, ou non, aux entrées nommées. Le jeton extérieur porte, ou non, la même empreinte.

Une attestation est différente. Le fichier affirme que la classe de risque provient d’un registre, que le nom humain vient d’une session authentifiée ou qu’un moteur de rejeu reproduit le résultat. Le lecteur ne peut pas le confirmer depuis le fichier. Exiger une origine nommée rend l’émetteur contredisible et améliore la responsabilité. Cela ne transforme pas l’origine déclarée en preuve.

Deux registres portant TR-4 peuvent donc reposer sur des mélanges opposés. L’un peut offrir surtout des calculs reproductibles ; l’autre dépendre d’assertions de l’émetteur sur les faits décisifs. L’indice ordinal masque cette composition.

Les schémas d’intégrité ont eux aussi des pouvoirs différents. Un condensat calculé par l’émetteur repère une modification ultérieure par un tiers, mais l’émetteur peut fabriquer une autre histoire et recalculer. Une signature rattache l’histoire à une clé et à une politique de confiance. Une ancre RFC 3161 ajoute un tiers qui signe une empreinte et un temps. Elle ne lit pas le témoignage et ne certifie pas son exhaustivité.

Le RFC 8785 fournit le contexte de canonisation JSON ; le projet précise néanmoins sa propre procédure sur les entrées couvertes. Le RFC 9162 et l’architecture SCITT illustrent des preuves placées au-delà d’un seul émetteur. Ils ne rendent ni vrai un périmètre auto-déclaré, ni exacte une croyance inscrite.

La matrice minimale

Un usage conséquent devrait associer au niveau : la version exacte de la spécification et son condensat ; l’identité de l’émetteur et du bord d’exécution ; le périmètre déclaré et la preuve indépendante éventuelle ; le résultat de chacun des quatre niveaux ; la liste et le nombre des contrôles vérifiés ; la liste et le nombre des contrôles attestés ; le schéma d’intégrité et les entrées couvertes ; l’autorité, la politique et le résultat de validation de l’ancre ; la version du validateur et du corpus ; l’heure de l’observation.

Cette matrice n’affaiblit pas le niveau. Elle protège ses réussites partielles. Un registre peut avoir une excellente intégrité et une provenance d’approbation encore attestée. Un autre peut montrer une vraie barrière d’action sans ancrage durable. Les deux situations cessent d’être forcées dans un classement trompeur.

La vie privée impose une autre limite. Le projet conseille de conserver un identifiant de source et un condensat plutôt que de recopier les données sensibles, et de rendre la censure visible. Il admet aussi que l’historique append-only et l’effacement tirent en sens contraire. Réécrire détruit la continuité ; garder le contenu « supprimé » n’efface rien. Aucun badge ne tranche ce choix juridique et opérationnel.

Le projet ne met pas davantage en œuvre le règlement européen sur l’IA parce qu’il parle de conservation et de surveillance humaine. Il exclut expressément cette conclusion. Une conformité technique ne devient pas une décision du régulateur.

La révision 01 est donc un progrès démontrable. Sa meilleure qualité est d’avoir rendu visibles les endroits où son ancien récit excédait ses preuves. Le bon usage du format consiste à préserver cette distinction, pas à la refermer sous un chiffre unique.

Sources

  1. Annonce IETF de la révision 01
  2. Statut dans l’IETF Datatracker
  3. Testimony Record, révision 01
  4. Testimony Record, révision 00
  5. Diff officiel entre les révisions 00 et 01
  6. Dépôt Machine Testimony
  7. Répertoire du recensement de conformité
  8. RFC 3161 — protocole d’horodatage
  9. RFC 8785 — canonisation JSON
  10. RFC 9162 — Certificate Transparency 2.0
  11. Architecture SCITT, révision 22
  12. Heng Lu sur la primauté du code opérationnel