Résumé

  • L’IETF a annoncé une réunion intérimaire en ligne du groupe OAuth le 28 septembre 2026, avec pour seul ordre du jour publié « Anthropic & OpenAI Agentic Use Cases ». L’avis ne prouve ni le soutien des entreprises à un texte déterminé, ni l’adoption d’un travail par le groupe.
  • RAR sait décrire un montant et un bénéficiaire précis ; DPoP sait lier un jeton à une clé. Il reste à empêcher les valeurs générées par le modèle de définir à la fois l’acte et leur propre permission. Une source indépendante doit autoriser l’état final, puis le premier point d’effet doit le comparer, consommer l’autorité et produire un reçu distinct du résultat.

La nuance peut se résumer par deux phrases. « Ce client est autorisé à utiliser le service de paiement » est une affirmation sur une capacité. « Ce client peut envoyer 123,50 euros à ce bénéficiaire maintenant » est une décision sur un acte. Un agent transforme souvent la première en seconde sans qu’un responsable n’ait validé les valeurs apparues entre les deux.

L’annonce de l’IETF fixe la réunion au 28 septembre, de 17 h à 18 h UTC. La présence d’Anthropic et d’OpenAI dans l’intitulé de l’ordre du jour ne révèle pas leur présentation, leur position ni une mise en œuvre. Une réunion programmée n’est pas un consensus, et un message de liste n’est pas un document de groupe.

La charte OAuth décrit une délégation limitée : donner à une application tierce un accès aux ressources sans lui transmettre les identifiants durables de l’utilisateur, voire son identité. Cette base répond déjà à plusieurs risques. RFC 9396 définit les Rich Authorization Requests et leur champ authorization_details. Son exemple de paiement porte un montant et un créancier. Si le bénéficiaire, la somme et le compte sont connus et approuvés, le serveur de ressources peut comparer la requête réelle à ces éléments.

Le débat ne doit donc pas caricaturer OAuth en mécanisme uniquement grossier. Le fil ouvert le 1er septembre pose une question plus précise : que se passe-t-il lorsque le nom de l’outil et ses arguments n’existent qu’après l’inférence du modèle ? Une injection dans un document peut modifier le destinataire tout en laissant valides le jeton, la portée et l’identité du client.

La réponse consacrée à RAR distingue l’expression de l’autorité de l’origine de l’autorisation. Copier les arguments du modèle dans un objet plus fin permet de les décrire exactement. Cela ne les rend pas légitimes. Le même résultat non fiable ne peut être à la fois la proposition d’acte et la preuve qu’il est permis.

La décision doit provenir d’un autre plan : mandat antérieur de l’utilisateur, budget assorti de limites, règle d’entreprise versionnée, commande contrôlée par un service distinct ou approbation d’exception. Elle peut être automatique ; « indépendante » ne signifie pas « manuelle à chaque appel ». Elle signifie que le candidat ne se délivre pas sa propre autorité.

Le projet Chen sur les cas d’usage rend le problème temporel. Alice demande un pique-nique le lundi ; le mardi, l’agent réclame parks.book et calendar.write après avoir choisi le lieu. L’écran a perdu le but initial, le parc et le coût : c’est l’effondrement du contexte. Le texte précise qu’OAuth n’a pas à interpréter le langage naturel ni à orchestrer la tâche. Il faut plutôt transporter les contraintes utiles jusqu’à l’action concrète.

Le projet Liu propose de transformer une opération structurée, sans l’instruction naturelle originale, en JWT de proposition, puis d’émettre un autre JWT pour l’opération confirmée. Qu’on retienne ou non ce format, la séparation reconnaît que la phrase de l’utilisateur n’est pas un contrat d’exécution tant qu’une partie responsable n’en a pas fixé les champs.

Le problème des mandats formulé par Yossif nomme T0 l’autorisation humaine et T1 l’exécution autonome. L’humain est absent à T1 par conception. Le rappeler pour chaque action détruirait l’autonomie lorsque les appels se comptent par milliers ; ne rien transporter de T0 laisserait les actes sans limites vérifiables. Le texte demande un contrôle déterministe par une autre partie, mais ne spécifie aucun protocole.

Ces trois textes, comme le quatrième ci-dessous, sont des Internet-Drafts. Ils peuvent évoluer, expirer ou être remplacés. Leur vocabulaire normatif ne lie pas les opérateurs et l’ordre du jour de septembre ne les transforme pas en RFC.

La liaison technique commence par une représentation canonique. Deux objets JSON peuvent permuter leurs clés sans changer de sens ; un nombre, une URL, une valeur par défaut ou le contenu actif d’un formulaire peuvent aussi modifier l’effet tout en échappant à une empreinte incomplète. La règle de canonisation doit être versionnée et couvrir l’outil, la destination, le montant, l’objet, la classe de conséquence et tout état vivant qui modifie l’acte.

L’empreinte n’est pourtant pas une autorité. Si le modèle propose un compte hostile, le hachage conserve fidèlement ce compte hostile. Il prouve que l’état exécuté correspond à l’état examiné ; il ne prouve pas que le mandant voulait cet état.

Le projet Das sur la liaison des appels esquisse un enchaînement : conserver le bloc comme « Candidate Act » sans effet, canoniser les arguments, valider, engager la preuve, délivrer une autorité limitée, la vérifier et la consommer au point d’envoi, puis invoquer. Il s’agit d’une soumission individuelle Informational assortie d’une note de propriété intellectuelle, pas de l’architecture choisie par l’IETF. Son apport testable tient dans l’emplacement : tool_use n’est pas invoke().

Le premier point capable de créer la conséquence est le vrai périmètre. Pour une API de paiement, ce peut être le serveur de ressources. Pour une fonction locale, la table de fonctions suffit déjà à écrire. Pour computer use, le contrôleur du navigateur peut soumettre un formulaire avant tout serveur conscient d’OAuth. Pour MCP, protéger un serveur ne ferme pas les autres routes du client. Une ancienne bibliothèque qui conserve les mêmes identifiants annule la garantie si elle contourne le contrôle.

Un message de suivi avance, à titre de formulation personnelle, que l’hôte ne devrait pas invoquer le point d’effet si l’empreinte finale ne correspond pas à une assertion de politique autorisée. Ce n’est pas une obligation IETF. C’est néanmoins un bon test : vérifier les valeurs vivantes, l’audience, l’expiration, le destinataire et l’état de rejeu, puis consommer atomiquement l’autorité à usage unique avant l’effet.

RFC 9449 apporte DPoP. Le mécanisme lie le jeton à une clé et détecte certains rejeux ; il n’atteste pas le jugement du porteur légitime. RFC 8693 organise l’échange de jetons et les sémantiques de délégation ou d’usurpation ; il ne décide pas que les paramètres terminaux satisfont le mandat. L’acteur, sa capacité et son acte restent trois faits.

Après l’envoi, un autre écart apparaît. Si l’autorité est consommée puis que l’hôte s’arrête avant la réponse, l’effet peut avoir eu lieu ou non. Répéter aveuglément peut doubler un virement ; abandonner peut perdre une opération légitime. Une identité d’idempotence commune, un état de rapprochement et des reçus séparant autorisé, soumis, accepté, engagé et observé sont indispensables. Un HTTP 200 n’est pas le résultat recherché par l’utilisateur.

Le reçu minimal remonte au mandat : identité et version de la politique, contexte de tâche, limites approuvées ; outil candidat, classe de conséquence, version de canonisation et empreinte finale ; source indépendante, émetteur, audience, expiration et clé ; point d’effet, empreinte vivante, contrôle de rejeu et consommation ; enfin réponse, état durable, compensation et effet visible. Sans cette chaîne, « annuler la tâche » ne sait pas quelles autorités sont actives ni quelles conséquences doivent être réparées.

Le principe de spécification initiale minimale de Heng Lu invite à normaliser seulement ce qui rend le mandat, l’acte, la liaison, le point d’effet et le reçu interopérables. Les seuils de risque et les choix d’approbation doivent rester attribuables localement, faute de quoi un format commun deviendrait un centre de pouvoir.

Sa réflexion sur les couches de réalité interdit les raccourcis : le jeton est un fait de protocole ; l’assertion de politique, un fait d’autorisation ; le reçu d’envoi, un fait d’implémentation ; la modification distante, un fait opérationnel ; l’objectif achevé, un fait de résultat. La primauté du code en fonctionnement fournit le verdict : changer le bénéficiaire après approbation, courir deux appels sur un seul droit, contourner l’enveloppe, tuer l’hôte après consommation. Si l’effet survit sans preuve correspondante, le système possède un discours d’autorisation, pas un contrôle.

Sources