Résumé

  • draft-templeman-scitt-measurement-capsule-00 définit un relevé tiers qui réunit déclaration, observation, écart, empreintes des preuves et limites sans attribuer de pouvoir d’exécution.
  • UNCHECKABLE n’est ni un échec, ni un succès, ni zéro, ni une absence ; une lecture partielle ne permet pas de fabriquer une conclusion complète.
  • Canonisation, hash, inclusion de Merkle, signature, reçu de transparence et horodatage répondent à des questions différentes. Toute sanction exige ensuite un principal, une politique et une voie de recours propres.

Un marché retire un fournisseur de son catalogue. La raison affichée est simple : une capsule signée porte l’état INCONSISTENT. Le service avait annoncé une capacité ; l’observateur ne l’a pas trouvée.

Pourtant, le relevé ne dit pas que le fournisseur a menti. Il ne dit pas que l’observation couvrait toutes les régions, tous les credentials ou la bonne version. Il ne dit pas non plus que l’émetteur de la capsule avait mandat pour fermer l’accès. La plateforme a transformé une différence en sanction et caché son propre acte derrière la signature d’un tiers.

C’est précisément le glissement que cherche à empêcher Declared-versus-Observed Measurement Capsules. Au 2 octobre 2026, le Datatracker classait la révision 00 comme soumission individuelle active, déposée le 27 septembre et expirant le 31 mars 2027. Le texte vise le statut Experimental. Il n’a ni flux IETF ni area director responsable. Il faut le lire comme travail en cours, non comme RFC, consensus, adoption par un groupe, certification ou preuve de déploiement.

Le format proposé permet à un mesureur extérieur au sujet et à l’action de comparer des octets déclarés avec une observation indépendante. Il fixe un authority_state unique : mesure seulement, aucune autorité d’exécution accordée ou enregistrée. Il interdit les champs qui tenteraient d’introduire décision, permission, refus, admission, approbation ou gate. Cette modestie n’affaiblit pas la capsule ; elle rend enfin visible le lieu où commence le pouvoir d’un autre acteur.

Deux faits acquis ne forment pas encore une vérité commune

La déclaration vient d’un artefact déterminé : manifeste, registre, carte d’agent, résultat signé ou description de protocole. Il faut retenir son adresse, sa version, son heure de lecture, son type et son empreinte. Le nom du sujet ne suffit pas. Un registre peut être en retard, un manifeste mis en cache, une carte servie selon l’identité du client.

L’observation a sa propre chaîne : point du réseau, authentification, requête, parser, timeout, horloge et méthode. Elle peut vérifier une signature, relancer une évaluation, lire un ledger ou interroger un endpoint vivant. Une mesure effectuée à Paris avec un compte anonyme ne réfute pas automatiquement une déclaration valable à Tokyo pour un client autorisé.

Le différentiel ne devrait donc pas être un verdict compact. Il doit nommer ce qui diffère et conserver les limites. INCONSISTENT signifie que deux représentations ne coïncident pas sous la comparaison indiquée. Il ne choisit pas la représentation vraie, ne prouve pas l’intention et n’identifie pas le responsable.

Le projet ajoute une échelle de force. Une preuve vérifiée contre l’engagement d’état d’un block header n’établit pas que ce header a été contrôlé contre le consensus. Une réponse d’API opérateur reste une assertion de l’opérateur. Une preuve conservée mais non vérifiée n’acquiert pas magiquement le niveau supérieur. Le constructeur doit refuser les sources qui exagèrent leur propre force.

L’impossibilité de vérifier doit rester visible

Les systèmes de score détestent les cases vides. Ils tendent à convertir l’inaccessible en zéro, l’incomplet en échec, ou à supprimer la ligne du dénominateur. La capsule impose au contraire UNCHECKABLE comme état positif de connaissance : nous savons que cette question n’a pas pu être tranchée par cette observation.

Pour affirmer NOT_LISTED, la lecture doit être complète. Une page tronquée, un endpoint paginé, un ledger permissionné ou une erreur d’identité produit UNCHECKABLE, pas une absence. De même, un total sur un inventaire partiel est interdit.

Cette discipline protège la gouvernance du dénominateur. Le batch doit indiquer sa règle d’inclusion et compter les lignes exclues par motif. Sans cela, l’émetteur peut sélectionner surtout les sujets qui divergent, publier des capsules exactes une à une et produire malgré tout une image agrégée trompeuse.

Les consommateurs devraient conserver trois populations : sujets éligibles, tentatives effectuées et observations complètes. Ils doivent aussi nommer celui qui a choisi la population. Un taux signé sans règle de sélection reste une narration chiffrée.

Les couches cryptographiques ne se remplacent pas

Le capsule_id est le SHA-256 des octets JCS selon RFC 8785, après retrait de son propre champ. Cette règle permet de recalculer l’identité du contenu. Les capsules sont ensuite triées, placées dans un fichier exact et engagées par une Merkle Tree Hash RFC 9162. Un audit path prouve l’appartenance au batch.

Le batch peut être signé sous COSE_Sign1, puis enregistré comme Signed Statement auprès d’un service de transparence SCITT. Un reçu atteste l’enregistrement selon la politique de ce service. Un mécanisme d’horodatage peut enfin borner l’existence temporelle du digest lorsqu’il atteint son état complet.

Chaque preuve reste bornée. Le hash désigne les octets. Le chemin de Merkle établit l’inclusion. La signature lie une clé aux octets. Le reçu établit une inscription. L’horodatage porte une proposition temporelle. Aucun ne calibre l’instrument, ne garantit l’exhaustivité de la lecture, ne rend l’observateur indépendant, ne montre l’accord du sujet ou n’autorise une sanction.

Le texte souligne aussi qu’une signature valide peut protéger de fausses données. Le prototype utilise une clé unique ; la compromission de la clé ou du credential du service de signature permettrait de re-signer une histoire falsifiée. Seul un ancrage antérieur, contrôlé indépendamment, rendrait cette réécriture détectable.

Référencer l’effet sans voler son résultat

Une capsule peut porter un effect_reference vers une déclaration signée selon un autre profil. Elle conserve le digest des octets enregistrés mais ne recopie pas l’outcome. Cette séparation permet de relier une autorisation, un reçu d’action et une mesure ultérieure sans prétendre qu’un même acteur a tout attesté.

Une approbation prouve au mieux qu’une clé autorisée a approuvé une action bornée. Elle ne prouve pas l’effet. La capsule décrit au mieux une comparaison ultérieure. Elle n’annule pas l’approbation et n’émet pas de décision de conformité. Le service de transparence rend les pièces retrouvables ; il ne les réconcilie pas.

Le projet d’implémentation n’a pas encore rempli ce membre. Il s’agit d’une composition proposée. Ce manque doit rester dans l’article : une interface conçue n’est pas un test d’interopérabilité.

Corriger signifie ajouter, puis réconcilier

Une capsule n’est jamais éditée. La correction produit une nouvelle capsule dans un nouveau batch et pointe vers le relevé remplacé, avec état initial, état corrigé et raison. L’ancienne pièce reste valide et accessible. Un changement de canonisation ou d’arbre crée lui aussi de nouveaux identifiants, même si le sens de la mesure paraît inchangé.

Ce modèle préserve l’histoire réellement consommée. Il permet de savoir si une plateforme a sanctionné avant la correction et si elle a revu sa décision ensuite. Mais l’append-only ne répare rien par lui-même. Les caches, scores et gates doivent écouter la supersession, réévaluer la politique et publier un reçu de restauration.

Le droit au recours devient donc une propriété technique. Le sujet doit pouvoir signaler une erreur, voir la méthode et obtenir une nouvelle mesure. Le décideur doit dire quelle version il a utilisée. Le mesureur doit conserver les limites. Sans cette chaîne, la transparence archive le tort au lieu de le corriger.

Les empreintes privées peuvent être devinées

Le champ sources conserve seulement des digests, pas les octets ni les URL. Cette réduction évite une divulgation directe, mais une petite valeur privée reste vulnérable à l’énumération. Une liste courte de statuts, une configuration prévisible ou un identifiant connu peut être hashé hors ligne jusqu’à trouver la correspondance.

Le projet recommande l’aveuglement pour les artefacts privés à faible entropie et précise que son prototype ne l’implémente pas. Il conseille aussi de limiter la mesure aux surfaces prévues pour les machines, de ne pas envoyer de credentials et de s’arrêter à la découverte MCP. Une limite de collecte peut créer davantage de UNCHECKABLE; c’est préférable à une intrusion accomplie sans mandat.

Le prototype ne clôt pas l’expérience

Le document rapporte un constructeur Python de l’organisation de l’auteur. Au 26 septembre, son index aurait lié 13 184 capsules, huit batches et sept types. Il mentionne des engagements OpenTimestamps et Rekor, un vérificateur web et un second programme sans code partagé avec le constructeur.

Ces chiffres sont des déclarations d’état d’implémentation de l’auteur. Le second programme appartient à la même organisation, et le texte reconnaît qu’il ne satisfait pas la demande d’implémentation indépendante. COSE_Sign1, l’enregistrement auprès d’un service SCITT, effect_reference et l’aveuglement ne sont pas réalisés.

L’expérience exige autre chose : un tiers doit réimplémenter le texte et retrouver les racines ; un service de transparence tiers doit enregistrer un batch ; un autre acteur doit vérifier le reçu ; deux émetteurs doivent être reliés ; les problèmes ouverts doivent être corrigés sans perdre l’histoire. Le projet promet un retrait si aucun de ces résultats n’apparaît dans les deux révisions suivantes.

Voilà une frontière saine entre code existant et preuve d’écosystème. L’un montre qu’une organisation peut produire ses propres objets. L’autre exige reproduction, opérateurs distincts et correction publique.