Résumé

  • Dans le premier Internet-Draft AAuth Events, la ressource remet un événement signé au fournisseur d'agents, ou AP, après une souscription ; celui-ci doit l'enregistrer durablement avant de répondre 202.
  • Cet acquittement couvre la garde du message par l'AP. Il ne prouve ni sa remise à l'agent, ni sa vérification, ni une action avant l'expiration du jeton.

Une file d'attente peut avoir parfaitement rempli son devoir et le destinataire manquer tout de même la nouvelle. C'est le point de départ utile pour lire AAuth Events, premier texte individuel de Dick Hardt daté du 28 septembre 2026. Le code 202 Accepted n'est pas un acquittement de l'agent. Il signifie que le fournisseur d'agents, destinataire intermédiaire, a accepté et conservé l'événement pour une remise ultérieure. Le mot « ultérieure » concentre le risque : le projet ne fixe pas la manière dont cette dernière remise a lieu.

Le document porte le suffixe -00 et vise une éventuelle Standards Track. Son existence dans le Datatracker de l'IETF n'en fait ni une RFC approuvée ni une pratique déjà déployée. Il complète un autre projet AAuth consacré à l'autorisation des agents. Dans le protocole parent, le fournisseur ne devait pas nécessairement connaître chaque ressource utilisée par la personne. Ici, la nécessité de joindre un agent absent du réseau pousse la ressource à déposer ses événements chez ce fournisseur toujours disponible. Ce déplacement du point de réception mérite autant d'attention que le format du message.

Le parcours commence par une souscription de l'agent aux événements d'une ressource. Lorsque l'événement survient, la ressource produit un jeton signé et lui associe un corps. L'AP vérifie notamment la signature de la ressource, le destinataire désigné, la souscription active et la concordance du corps avec l'empreinte body_s256. Le projet lui permet d'écarter des doublons à partir du couple émetteur-identifiant. Ces opérations établissent les conditions d'une acceptation valide. Elles ne prouvent pas que l'agent est connecté, qu'il a reçu le corps, ou qu'il en a compris la portée.

L'obligation de stockage avant réponse est précise. Un AP ne doit pas envoyer 202 après une simple lecture fugace des octets : il doit d'abord inscrire durablement l'événement accepté en vue de sa remise. Un opérateur peut donc attribuer une valeur réelle à cette réponse. Elle évite de traiter un paquet volatil comme un dépôt réussi. Mais elle ne franchit qu'une frontière, celle entre ressource et AP. Le mécanisme AP-vers-agent reste propre à la plateforme et hors du champ du texte. Aucun canal de livraison universel, reçu final ou délai garanti ne découle du 202.

Prenons une alerte d'ouverture d'un créneau de réservation destinée à un agent éteint. L'AP peut recevoir le message, le conserver sans altération et répondre correctement à la ressource. Si la plateforme ne réveille l'agent qu'après la fin de validité du jeton d'événement, l'agent doit refuser d'agir sur ce message expiré. L'exemple illustre une possibilité logique, non un incident documenté. La persistance du message ne prolonge pas sa fenêtre d'action. Une interface qui afficherait « notification accomplie » dès le 202 fusionnerait deux états que le projet sépare explicitement.

L'empreinte du corps ne ferme pas non plus la brèche temporelle. body_s256 aide l'agent à repérer une modification ou une substitution du contenu par l'intermédiaire. Le projet relève expressément qu'elle n'empêche pas l'AP de retenir ou de retarder l'événement. Même si le contenu reste authentique, l'agent doit encore contrôler le jeton, son audience, l'empreinte du corps et la pertinence pour son contexte local. Il ne doit pas agir si le jeton est expiré ou si le corps ne correspond pas. Un reçu de l'AP, un reçu éventuel de l'agent et la décision de l'agent sont donc trois objets de preuve différents.

La même architecture a un coût de confidentialité. Pour assurer ce service, l'AP voit les identités des ressources auxquelles ses agents s'abonnent et le contenu des événements. Le projet souligne lui-même l'écart avec l'effort du protocole AAuth parent pour ne pas exposer au fournisseur les usages de ressources d'une personne. Ce constat ne démontre ni surveillance effective par une plateforme, ni impossibilité de réduire les données transmises. Il oblige toutefois à expliciter un choix : la disponibilité du guichet s'achète par une nouvelle visibilité sur les relations et les messages.

Le fournisseur n'est pas simplement un transporteur neutre et aveugle.

Le test de gouvernance n'est donc pas « avons-nous obtenu un code de succès ? ». Il porte sur la chaîne de garde : qui peut attester l'inscription à l'AP, qui peut attester la remise à un agent encore en mesure d'agir, et que voit l'intermédiaire pendant ce service ? Le projet règle une partie du premier point, laisse la dernière livraison à l'implémentation et expose le compromis de confidentialité. Il serait prématuré de transformer ce schéma initial en promesse de fiabilité de bout en bout.

Sources