Résumé

  • Le projet individuel du 28 octobre décrit un enregistrement de verdict : une assertion de l’émetteur, des empreintes de pièces citées et la règle qui a produit le résultat.
  • Le vérificateur emploie ses propres règles et documents. Il rapporte released, held ou refused avec les étapes contrôlées, sans qualifier le dossier entier de « vérifié ».

Un résultat n’est pas un passeport

Le producteur d’un verdict choisit souvent le plus joli mot pour le présenter. Darren Wright lui laisse une place pour écrire son résultat, mais réserve à un autre acteur la décision de le contrôler. Son texte déposé à l’IETF est un Internet-Draft individuel, destiné à une publication expérimentale. Il propose un format de dossier, pas un vote de confiance en faveur de l’émetteur.

Le dossier est un objet JSON canonique. Il contient notamment l’identité déclarée du rédacteur, l’affirmation examinée, les empreintes SHA-256 des pièces invoquées et le nom de la règle appliquée. Un résultat peut venir d’une vérification mécanique ou d’une décision de modèle. La signature et la borne temporelle viennent du conteneur qui transporte cet objet. Une déclaration signée dans SCITT avec son reçu est un exemple de conteneur, parmi les possibilités que le projet laisse ouvertes. La belle écriture du JSON ne signe rien à elle seule.

Le contrôle commence par une question de possession : le lecteur a-t-il les pièces entières ? Pour chacune, il calcule lui-même l’empreinte et vérifie le format annoncé. Une pièce absente laisse l’étape NOT RUN. Un format que sa politique ne sait pas accepter a le même effet. Si la règle est calculable, il la relance sur les valeurs annoncées et compare le résultat. Une différence est un échec. Le simple jugement, sans reproduction mécanique, ne peut entrer que dans les catégories que sa propre politique a admises.

Ce « sa propre » porte tout le poids du texte. La politique, les ancres de confiance et les spécifications de règles viennent du vérificateur. Les données qu’il utilise pour réussir une étape doivent être calculées à partir des octets qu’il détient ou provenir de ces choix indépendants. L’émetteur peut décrire ce qu’il pense avoir fait. Son témoignage ne peut transformer un contrôle impossible en réussite. Le présentateur peut retenir une pièce embarrassante ; l’absence bloque une étape, elle n’en valide aucune.

Le projet donne ensuite quatre sorties. Toutes les étapes passent : dossier released. Une étape échoue : refused. Une étape manque d’entrée sans échec ailleurs : held. Si la politique du vérificateur est invalide, il n’y a no verdict. Le rapport conserve la raison de chaque étape, la borne temporelle et l’empreinte des politiques utilisées. Il interdit, pour le dossier pris en bloc, les étiquettes « vérifié », « valide », « vrai », « fiable », « prouvé », « confirmé » ou « OK ». Le vocabulaire du tableau de bord perd son raccourci préféré.

Même l’état released a une portée précise : l’émetteur a formulé ce résultat à partir de ces pièces et de cette règle au plus tard à la borne établie. La vérité de l’affirmation reste une autre question. Un registre de décisions peut ainsi être inspectable sans se déguiser en tribunal universel.

Sources : projet Wright, statut IETF, RFC 9943, RFC 8259.