Résumé

  • La fiche publique de la demande AUDIT porte l’état Declined. La liste non-WG ouverte le 31 août 2026 sert à retravailler un BoF et une charte éventuels ; elle ne constitue pas un Working Group.
  • L’IESG a reconnu l’intérêt de l’audit des actions d’agents, mais a demandé un objet plus étroit et une démonstration précise de ce qui manque à OAuth, WIMSE, OpenTelemetry et aux travaux voisins.
  • Le projet d’architecture distingue interactions, actions, délégations et transitions d’autorisation. Il ne résout ni le refus d’enregistrer, ni la collusion générale, ni l’alignement du modèle, et reporte encore l’analyse détaillée des menaces.
  • Un reçu public d’état d’autorité doit conserver séparément discussion, décision de BoF, charte, adoption d’un draft, revue IETF, publication et déploiement.

Une chronologie que l’on ne doit pas raccourcir

Le 31 août, le Secrétariat de l’IETF a annoncé la création de la liste AUDIT. Le geste est positif : une question transversale dispose enfin d’un lieu visible pour confronter ses hypothèses. Mais il arrive après une décision qui n’a pas disparu. La demande de BoF AUDIT, version 02 est enregistrée comme « Declined BOF request » et son état courant est « Declined ». L’index général des demandes de BoF confirme ce classement.

La date du 6 juillet, dernière mise à jour de la fiche, compte autant que le libellé. Les champs de responsabilité sont vides. Le texte de la proposition cite les Area Directors de la Security Area et propose Yaroslav Rosomakho comme président, mais ces mentions décrivent le montage espéré. Elles ne sont ni une nomination ni une charte approuvée.

La nouvelle liste se décrit avec une précision remarquable. Dans l’annuaire des listes non rattachées à un WG, elle est destinée à la discussion d’un possible BoF AUDIT, à la révision d’une charte proposée et à un effort vers la création d’un groupe de travail. Au 1er septembre, les archives de la liste ne contiennent que l’annonce de création. L’avenir institutionnel est ouvert ; le présent ne l’est pas moins clairement.

Cette séparation ne relève pas d’une anomalie. Les règles applicables aux listes non-WG prévoient justement des listes conçues pour préparer un futur WG. Un Area Director compétent autorise la création du canal. Son approbation porte sur ce canal, pas sur un BoF, une charte, des livrables ou des responsables que le canal pourrait un jour aider à établir.

Le contraste avec le RFC 2418 sur les groupes de travail est instructif. Un WG reçoit une charte délimitée, des responsables, des étapes et une place dans un Area. Il doit disposer d’une liste de diffusion. Mais cette obligation ne permet pas l’inférence inverse : toute liste n’est pas un groupe, de même que toute consultation n’est pas une décision.

Le mot du message et l’état du registre

Le 3 juin, le retour de l’IESG parlait de demande « deferred ». Nous le savons parce que les promoteurs l’ont reproduit dans leur réponse du 5 juin. Le message ne niait pas le besoin. Il jugeait bonne l’idée d’auditer les actions d’agents, tout en estimant la proposition actuelle trop vaste. Il demandait un resserrement, des échanges avec OAuth et WIMSE, et une explication convaincante de la différence avec les mécanismes existants ou un profil OpenTelemetry. Il suggérait aussi que certaines notions d’intention et de politique pouvaient relever davantage d’un cadre juridique que d’un protocole IETF.

Les auteurs ont contesté le sens procédural et le moment de ce report, défendu le problème des preuves dispersées entre domaines et poursuivi la discussion de périmètre. Ce désaccord appartient au dossier de décision. Il n’accorde pas, par lui-même, l’autorité qui était demandée.

Il n’est pas nécessaire de choisir artificiellement entre « deferred » et « Declined ». Le premier terme décrit la formulation de l’échange de juin ; le second est l’état actuel du registre. Un dossier fidèle conserve les deux, leur date et leur source. Il peut aussi laisser place à une nouvelle demande. Dire que le dossier présent est refusé n’équivaut pas à prophétiser l’échec définitif du sujet.

Cette rigueur répond à un problème plus large. Comme le montre l’essai de Heng Lu sur le mirage multi-parties prenantes, la présence dans une enceinte et la participation à ses échanges ne suffisent pas à identifier un mandant ou à établir une délégation. Ici, l’adresse de liste identifie un public de discussion. Elle n’autorise personne à parler au nom d’un WG AUDIT inexistant.

Ce que l’architecture cherche réellement à relier

Le draft individuel sur l’architecture AUDIT, daté du 18 mai, part d’un cas difficile. Un utilisateur confie une tâche à un agent. L’agent délègue, appelle des outils dans plusieurs domaines administratifs, obtient des autorisations supplémentaires et provoque un effet. Chaque système possède peut-être un journal, sans qu’aucun ne raconte correctement l’instruction, l’autorité transmise, l’exécution et les changements de permission.

Le texte ordonne ce puzzle autour de quatre familles. Les Interaction Records recueillent les échanges visibles par l’utilisateur, dont demandes et approbations. Les Action Records décrivent l’opération à la frontière où elle s’est produite. Les Delegation Records documentent l’autorité confiée, sa portée et ses contraintes. Les Authorization Transition Records décrivent une permission initiale, une élévation, un resserrement, une révocation ou une expiration.

Un contexte d’audit commun peut transporter des identifiants de corrélation et des références aux étapes précédentes. Chaque acteur produit sa propre perspective. Un dépôt d’audit peut normaliser et présenter les éléments, tandis que des mécanismes optionnels d’attestation et de transparence renforcent certaines preuves. Cette décomposition est utile : elle empêche de traiter une intention, une délégation et un résultat comme trois écritures interchangeables dans le même log.

Le draft fixe aussi ses non-solutions. Il ne suppose pas l’agent digne de confiance et n’accorde qu’une confiance partielle au dépôt d’audit. Il ne peut obliger un service à enregistrer ce qui s’est passé chez lui. Il ne résout pas une collusion couvrant tous les rôles, ni l’alignement du modèle. Le modèle de menace détaillé reste à construire. Un historique signé peut donc être authentique et incomplet à la fois.

Les risques de confidentialité se trouvent au cœur de l’objet. Une interaction révèle des requêtes et une intention ; une action révèle outils, fournisseurs et opérations ; un identifiant global peut suivre une personne au travers d’organisations sans rapport. Même l’inscription d’un simple condensat dans un registre de transparence divulgue l’existence d’un événement à une heure donnée. L’audit n’est pas automatiquement l’opposé de la surveillance : sans limites, il peut en devenir l’infrastructure.

Un autre texte individuel sur les conversations vérifiables avec des agents propose une piste pour la preuve côté utilisateur. Il n’est pas un document adopté par AUDIT, puisqu’aucun WG AUDIT n’existe. En outre, signer une conversation ne décide ni la minimisation, ni la divulgation sélective, ni la durée de conservation, ni le lien sûr entre les paroles et une action ultérieure.

Les briques voisines ont des frontières

La demande de cartographier OAuth, WIMSE, OpenTelemetry et d’autres travaux évite de confondre un problème transversal avec un droit général de redéfinir chaque protocole voisin.

Le RFC 8693 sur OAuth Token Exchange représente des délégations et des chaînes d’acteurs entre échanges de jetons. Il éclaire l’autorité passée d’un composant à l’autre. Il ne fournit pas toute l’instruction humaine, les transitions ultérieures, le résultat exécuté et l’appréciation d’un auditeur. Le protocole de base laisse d’ailleurs hors périmètre les sémantiques détaillées des jetons, leurs propriétés de sécurité et les modèles de confiance.

La recommandation W3C Trace Context propage des identifiants pour relier les segments d’une requête distribuée. Cette corrélation dit où regarder. Elle ne dit pas si l’acteur pouvait agir, si la délégation avait été réduite, si l’utilisateur avait approuvé une étape ou si le résultat était juste. La continuité d’une trace n’est pas une chaîne d’autorité.

Le RFC 9334 et l’architecture RATS organisent l’attestation : un Verifier apprécie des Evidence, puis un Relying Party applique sa politique à l’Attestation Result. Cela aide à évaluer un composant ou un environnement. Cela ne prouve ni pouvoir juridique ni fidélité sémantique à l’intention. Une machine intègre peut exécuter avec exactitude une action interdite.

Le RFC 9943 consacré à SCITT décrit déclarations signées, service de transparence append-only et reçus d’enregistrement ou d’inclusion. Il rend certaines suppressions ou réécritures plus visibles. Il ne rend pas vraie la déclaration enregistrée, ne démontre pas que l’ensemble est complet et ne transforme pas l’intégrité cryptographique en permission.

Ces limites dessinent une méthode. Chaque groupe voisin doit conserver la maîtrise de ses protocoles. Le futur périmètre AUDIT, s’il existe, devrait nommer les jointures interdomaines qui restent sans propriétaire, plutôt que présenter OAuth, la télémétrie, l’attestation et la transparence comme des modules indistincts d’une architecture déjà acquise.

Un reçu pour l’institution qui conçoit des reçus

Le projet contient une symétrie utile. AUDIT veut documenter qui a autorisé une action d’agent. L’IETF doit, en parallèle, permettre au public de savoir qui a autorisé le travail de normalisation. Dans les deux cas, une donnée de corrélation ne peut remplacer l’autorité qu’elle est censée documenter.

Un reçu public devrait d’abord stabiliser l’identité du problème et la version exacte de la proposition. Il indiquerait l’état : idée, BoF refusé ou reporté, discussion non-WG, BoF approuvé, charte en examen, WG actif ou travail terminé. Pour chaque transition, il nommerait l’acteur compétent, la décision datée et son URL, sans amplifier ses mots.

La différence de périmètre avec l’état précédent est essentielle. Qu’a-t-on retiré ? Quel groupe voisin reprend quelle fonction ? Les responsables ne deviennent titulaires qu’après nomination ; auparavant, ils restent proposés. Le lieu de discussion dispose de son propre champ. Une charte absente donne une valeur nulle, pas une approximation tirée d’un texte de demande.

La même discipline vaut pour les documents. Un draft individuel reste individuel jusqu’à une adoption explicite. Adoption, Working Group Last Call, IETF Last Call, évaluation IESG et objections non résolues constituent des états distincts. Publication doit préciser le flux et la catégorie du RFC, sans employer « standard » comme raccourci universel. Les implémentations et la politique de production forment encore une autre couche.

Le reçu doit conserver les anciennes décisions. Un nouveau BoF réussi ne change pas rétrospectivement le sens du refus antérieur ; il doit exposer le delta qui a obtenu un résultat différent. Une adoption future ne fait pas des révisions individuelles antérieures des textes de WG. Ainsi l’historique explique la formation du mandat au lieu de produire seulement sa dernière photographie.

À la date de cette analyse, le reçu AUDIT tient en quelques lignes : des drafts individuels existent ; la version 02 d’une demande de BoF a reçu un retour critique ; le registre la classe Declined ; une liste non-WG vient d’être créée pour retravailler le BoF et sa charte ; aucun responsable officiel, aucune charte approuvée, aucune adoption par un WG et aucun consensus IETF ne sont établis.

Une architecture de preuve doit montrer ses absences

Le prochain périmètre, s’il se précise, devra faire de la confidentialité une propriété initiale. Chaque famille de dossiers a besoin de sa propre minimisation. Les contenus qui n’ont pas à traverser les frontières peuvent rester détachés, représentés par un condensat ou révélés sélectivement. Des identifiants opaques ou bilatéraux doivent remplacer l’identifiant global chaque fois qu’une corrélation universelle n’est pas indispensable.

L’accès de l’auditeur nécessite une autorisation distincte. Les délais de conservation diffèrent selon qu’il s’agit de diagnostic opérationnel, de preuve contractuelle, d’incident de sécurité ou d’obligation réglementaire. Le système doit signaler les lacunes, les refus d’enregistrer et l’indisponibilité au lieu de fabriquer une histoire continue. Enfin, le reçu doit dire quel élément précis il couvre, jamais suggérer qu’il couvre tous les événements pertinents.

La liste AUDIT est donc une bonne nouvelle à condition de la nommer correctement. Elle donne aux participants le moyen de réduire l’objet, de répartir les responsabilités et de rendre les limites de preuve explicites. La sobriété du statut protège ce travail : elle empêche une marque institutionnelle prématurée de remplacer les décisions qui restent à prendre.