Summary

  • Le projet AACP demande à un service de confirmation d’afficher, hors de l’inférence du modèle, tous les paramètres marqués comme soumis à l’accord humain, puis de signer la décision.
  • Le système chargé d’agir vérifie ensuite la signature, l’empreinte de l’opération, son destinataire, sa fraîcheur et son usage unique. Un refus signé et une réponse impossible à obtenir suivent des chemins différents.

« L’utilisateur a validé. » Dans une chaîne d’agents, cette phrase peut voyager très loin sans que personne sache quel prix, quel destinataire ou quelle suppression elle désignait. Le projet Agent Action Confirmation Protocol du 2 novembre replace la preuve au moment où une action devient réelle. L’agent qui s’apprête à agir décrit l’opération dans un objet structuré. Un service de confirmation présente à la personne les champs dont l’accord est exigé, lui donne deux commandes explicites et signe sa réponse. Ce service peut faire partie de l’application de l’utilisateur ou de l’infrastructure d’autorisation d’une entreprise : la séparation décisive est celle entre l’écran de décision et l’inférence du modèle.

Le détail du formulaire est une question de pouvoir. Le descriptif de l’action indique quels paramètres portent confirm=true et leur nom lisible. Le service doit les montrer tous avant d’afficher les commandes accepter et refuser. Il traite noms et valeurs comme des données, sans exécuter le moindre lien ni la moindre instruction glissée dans le texte. L’agent peut proposer une formulation séduisante ; il ne choisit pas à lui seul ce qui disparaît de la vue humaine. Le montant et le destinataire d’un virement doivent rester visibles lorsque l’écran s’allume.

La signature vient du service qui a réellement montré les champs et recueilli la décision. Le vérificateur recalcule l’empreinte de l’opération sur la requête qu’il va exécuter. Il examine aussi la clé du service selon sa propre politique de confiance, l’agent auquel la preuve est destinée, le défi frais, la durée de validité et les identifiants déjà utilisés. Le texte recommande, surtout pour une action irréversible, de contrôler une seconde empreinte portant sur les champs effectivement affichés. Ce contrôle oblige le système à répondre à deux questions distinctes : la personne a-t-elle cliqué, et sur quoi a-t-elle cliqué ?

Le refus reçoit un traitement qui lui appartient. La réponse denied est signée et interdit à l’agent de relancer automatiquement la même demande ; une nouvelle tentative doit venir de l’utilisateur. Unobtainable indique qu’aucune réponse n’a pu être recueillie et reste un statut non signé. Une preuve périmée, réutilisée, destinée à un autre agent ou liée à d’autres paramètres produit encore d’autres résultats. Pour une API qui déplace de l’argent ou efface un enregistrement, confondre ces cas reviendrait à donner au silence la même valeur qu’à un non.

Le registre de l’IETF classe AACP comme projet individuel. Son architecture de preuve est écrite ; la pièce qui manque est un essai interopérable montrant qu’un vérificateur rejette une valeur modifiée, un champ caché et une preuve rejouée. C’est là que se mesurera la distance entre une belle demande d’autorisation et un système capable de l’imposer.