Résumé

  • Déposé le 28 septembre 2026, le premier projet individuel AAuth-R3 envisage l'exécution préalable d'un appel retenu uniquement si cette exécution ne produit aucun effet extérieur au résultat. Il ne s'agit ni d'une RFC, ni d'une adoption par l'IETF, ni d'un déploiement constaté.
  • L'écran doit annoncer que l'opération a déjà eu lieu et que la décision porte sur la remise du résultat à l'agent. Le service peut alors présenter la taille et les catégories réelles de la réponse.
  • Si lancer l'appel génère une piste d'audit, consomme un quota, déclenche une facturation ou sollicite un tiers, le consentement doit précéder l'exécution. L'étiquette « lecture seule » ne règle pas cette question.

Le contenu de la décision change

Imaginons une recherche dans des dossiers de salariés. Le service obtient des lignes comprenant des rémunérations et des adresses, mais garde la réponse. Demander à la personne si elle « autorise la recherche » serait trompeur : celle-ci est achevée. Elle peut encore refuser que l'agent reçoive ces données. La section 10.4 du nouveau texte AAuth-R3 exige donc que l'affichage distingue clairement l'exécution passée de la divulgation proposée.

Ce décalage offre aussi une information que la seule formulation de la requête ne donne pas. Le service sait combien de lignes sont sorties et quelles familles de champs elles contiennent. Un élément result, facultatif et présent uniquement après exécution, peut décrire cette portée dans la proposition de consentement. Il ne transporte pas les données elles-mêmes. Le service conserve la faculté de ne pas divulguer certains éléments ou de les masquer, et choisit ce que le service de présentation et la personne peuvent connaître. Une approbation fondée sur une description trop pauvre reste une décision fragile, même si les références cryptographiques sont correctes.

La restriction décisive est ailleurs : faire tourner l'appel ne doit rien changer en dehors de la réponse conservée. Une consultation peut être dite « en lecture » et néanmoins débiter un crédit, produire un journal d'accès soumis à audit, compter dans une limite de fréquence ou appeler un prestataire. Ce sont déjà des conséquences. Retenir les octets du résultat ne retire ni la facture ni l'événement d'audit. Le projet impose alors l'accord avant l'exécution, et non un accord tardif rebaptisé autorisation.

La proposition liée à un appel, pas à une intention vague

Selon Datatracker, la version -00 reste une soumission individuelle à l'état I-D Exists. La mention d'une trajectoire Standards Track dans l'en-tête n'est pas une ratification. Le document décrit une proposition pour un seul appel, avec opération et paramètres précis, référencée par r3_uri et r3_s256. Dans le flux HTTP 202, le service retient l'invocation. Dans le flux 401, où l'agent recommence, le service doit comparer les paramètres réels à ceux approuvés ; une valeur représentée par une empreinte doit être identique octet pour octet. Un même jeton ne doit pas permettre deux exécutions.

Lorsque le résultat qualifiant est déjà fixé, l'accord peut viser cette réponse précise, sans risque qu'une deuxième exécution produise d'autres lignes. Mais fixer la réponse n'autorise pas automatiquement sa remise. Le service détient toujours le choix de ce qu'il décrit et de ce qu'il livre. C'est ce partage des responsabilités, plutôt que la simple présence d'un bouton, qui mérite l'attention des responsables de gouvernance.

Les articles voisins de BTW portent sur le total de budgets AAuth concurrents et sur la remise d'événements par un intermédiaire ; celui-ci porte sur l'instant où un humain approuve la sortie d'un résultat déjà existant.

Sources