Résumé

  • La révision 03 de draft-wilder-scitt-physical-site-engage-receipt, enregistrée le 9 septembre 2026 et datée du 10 septembre, inscrit le mode d’attestation dans chaque reçu et impose le résultat undetermined lorsque certains faits publiés par l’émetteur ne peuvent être résolus. Elle reste un Internet-Draft individuel actif, sans adoption par le groupe SCITT ni approbation de l’IETF.
  • Le nouveau texte reconnaît surtout une relation absente : ni le reçu ni les faits externes prévus ne disent qui relie le propriétaire du site au service de transparence. Un service peut donc être indépendant de l’émetteur sans être indépendant du propriétaire du site.

Un prestataire intervient dans un entrepôt. Le système produit un relevé signé, atteste l’environnement d’exécution et fait enregistrer la déclaration dans un service de transparence. Le client reçoit une preuve cryptographique que l’entrée figure bien dans la structure vérifiable de ce service. À première vue, la chaîne semble avoir multiplié les contrôles.

Il manque pourtant une question institutionnelle : qui commande le service de transparence ? Si le propriétaire de l’entrepôt en est aussi l’opérateur, le journal est extérieur à l’émetteur du reçu, mais pas à l’acteur qui contrôle le lieu et peut avoir intérêt au contenu visible. Ce propriétaire n’a pas besoin de fabriquer une signature pour peser sur le dossier. Il peut disposer d’une capacité de rétention ou de non-publication sur son propre service.

La révision 03 du Physical-Site Engagement Receipt, ou PSER, formule désormais ce problème elle-même. C’est un progrès de transparence documentaire. Ce n’est pas encore un mécanisme qui permet au vérificateur de résoudre la relation manquante.

Une modification de fond dans une soumission individuelle

La fiche Datatracker décrit un Internet-Draft individuel actif. Aucun flux RFC ni statut RFC visé n’y est renseigné. La couverture du document demande une trajectoire Standards Track, mais ce souhait de l’auteur ne vaut ni adoption par un groupe de travail, ni consensus, ni norme. L’historique enregistre la version 03 le 9 septembre à 22 h 26 PDT ; le document porte la date du 10 septembre.

La version 02 faisait dépendre quatre obligations d’un « manifeste de l’émetteur » qu’elle ne définissait pas. La comparaison officielle montre comment la version 03 démonte cette ambiguïté. Le profil passe de wilder.pser/0.4 à wilder.pser/0.5. Chaque reçu doit désormais porter attestation.bindingMode, avec un choix fermé entre témoin direct et témoin délégué. En mode direct, une différence entre la clé témoin et la clé iss de l’enveloppe entraîne le rejet.

Deux informations restent réellement externes : l’autorisation du signataire délégué et la relation entre l’émetteur et le service de transparence. Elles doivent être récupérables à un identifiant stable sous le contrôle de l’émetteur, lui-même découvrable depuis iss. Une réponse mise en cache cesse d’être valable lorsque la clé de signature change.

L’échec de cette récupération ne devient ni un non, ni un oui. Il devient undetermined. Le vérificateur doit transmettre cette incertitude, ne peut pas prétendre avoir constaté l’absence d’un fait qu’il n’a jamais pu lire, et ne peut pas choisir silencieusement l’option la plus favorable à l’émetteur. Pour autant, il ne rejette pas le reçu pour ce seul motif : la politique de la partie utilisatrice décide de la conséquence. Le résultat technique et le verdict professionnel restent séparés.

Le triangle d’affiliation est incomplet

Trois relations bilatérales structurent la garde du dossier.

La relation émetteur–propriétaire du site voyage dans le reçu. Le champ issuerAffiliation indique AFFILIATED, INDEPENDENT ou NOT_DISCLOSED. Il s’agit d’une déclaration signée, non d’une vérification universelle des liens capitalistiques, mais sa provenance et sa date restent attachées à l’intervention.

La relation émetteur–service de transparence se trouve hors du reçu parmi les faits publiés par l’émetteur. Le service peut être opéré par l’émetteur, par une entité liée ou par une partie sans lien. Lorsque cette dernière qualité est établie, le reçu d’inclusion fournit un élément extérieur à l’émetteur. Lorsque la source ne se résout pas, le résultat demeure indéterminé.

La relation propriétaire du site–service de transparence n’a, dans cette version, ni membre dans le reçu ni fait externe défini. La nouvelle section 7.9 l’énonce sans détour. Un émetteur peut être indépendant des deux autres acteurs, satisfaire ainsi les deux déclarations existantes, alors que le propriétaire du site exploite le service qui reçoit les enregistrements.

Dans ce cas, « extérieur à l’émetteur » ne signifie pas « extérieur au site ». Le texte précise que le propriétaire peut encore supprimer de la vue ou retenir des entrées relatives à son propre site. Il ne prétend pas qu’une telle conduite a eu lieu. Il décrit une faculté que les données présentées ne permettent pas d’écarter.

Une présence vérifiée n’est pas une histoire complète

Le socle SCITT ne promet pas davantage. Le RFC 9942 définit les reçus COSE comme des preuves signées portant sur une structure de données vérifiable. Une preuve d’inclusion valide confirme qu’une entrée appartient à cette structure. Le RFC 9943 distingue la déclaration signée par l’émetteur, son enregistrement par un service et l’évaluation ultérieure par la partie utilisatrice.

Ces fonctions peuvent rendre une altération détectable et un historique observable. Elles ne certifient pas l’indépendance juridique ou économique de l’opérateur du journal. Elles ne prouvent pas non plus que l’ensemble des reçus produits a été soumis. Le projet PSER le dit expressément : l’enregistrement obligatoire d’un reçu ne démontre pas que l’émetteur les a tous enregistrés. Sa chaîne locale de hachage ne détecte pas une fin de séquence retenue sans point d’ancrage extérieur déjà conservé.

L’écart devient décisif quand un document sert à attribuer un crédit SLA, calculer une couverture d’assurance, conclure un audit ou apprécier un litige. Une politique peut se contenter d’une signature authentique. Une autre peut exiger un service indépendant de l’émetteur. Une troisième peut exiger une preuve indépendante aussi du propriétaire du site. Les trois exigences ne sont pas interchangeables.

Ne pas effacer l’état indéterminé

La nouvelle règle de résolution offre le bon vocabulaire. Une panne réseau ne doit pas se transformer en preuve d’indépendance ; un document illisible ne doit pas devenir une accusation d’affiliation. La relation propriétaire–service doit suivre la même discipline tant qu’elle reste externe au format.

Si elle n’a pas été vérifiée, elle reste indéterminée jusqu’à la décision. Si une source datée l’établit, la source et son heure d’observation accompagnent le résultat. Un changement de contrôle ultérieur produit un nouvel état ; il ne réécrit pas le reçu antérieur. Deux services peuvent réduire la dépendance, mais deux services sous le même contrôle ne constituent pas deux témoins indépendants.

Cette précision ne conduit pas à interdire toute affiliation. Dans certains usages, elle sera connue et acceptable. Dans d’autres, elle disqualifiera le dossier. Le principe commun consiste à exposer la relation réellement testée et la règle qui lui donne un effet.

Ajouter un registre de garde à trois arêtes

Le complément minimal est un registre de garde à trois arêtes évalué avec le reçu. Il relie l’identité et la version du reçu aux relations émetteur–site, émetteur–service et site–service. Pour chacune, il conserve l’état, la source, la date de résolution et l’éventuelle incertitude, puis nomme l’exigence d’indépendance choisie par la partie utilisatrice.

Il ajoute l’identité du service, le point de contrôle d’inclusion et son heure, l’éventuel second service ou observateur indépendant, la décision, sa raison et la chaîne de correction. Les données sensibles sur le site peuvent rester protégées ; une projection publique bornée peut simplement dire quelle relation a été établie, non résolue ou jugée non nécessaire.

Ce registre ne transforme pas SCITT en assureur ni en régulateur. Il empêche une preuve valide d’inclusion de devenir par glissement une preuve d’indépendance. La signature répond à la question du signataire. L’attestation fournit une preuve circonscrite sur l’environnement de production. Le reçu dit qu’une déclaration a été incluse. Le registre de garde dit si le service satisfaisait la politique institutionnelle appliquée à la décision.

Cette séparation reprend le test des surfaces de contrôle de The Policy Mirror et l’exigence d’exécution observable de Running-Code Primacy. Reality, Not Advocacy impose la retenue éditoriale correspondante : reconnaître la lucidité d’un projet sans annoncer le résultat qu’il ne fournit pas. Le registre proposé ici relève de mon analyse, non d’une décision de l’IETF.

La révision 03 a rendu visible la bonne frontière. La prochaine étape consiste à la rendre vérifiable, afin qu’un reçu parfaitement valide ne soit jamais chargé d’une indépendance qu’il ne contient pas.

Sources