Summary

  • draft-li-oauth-delegated-authorization-03 décrit une racine signée par le serveur d’autorisation, puis des jetons enfants signés localement et liés à la clé du client suivant ; le détenteur final présente la chaîne complète avec une preuve DPoP.
  • La validation peut établir la continuité des clés et la réduction des permissions, de l’audience, de la durée et de la profondeur. Elle n’établit ni le motif du choix d’un délégué, ni l’intention concrète d’une personne, ni la réception d’une révocation par un serveur hors ligne.
  • Daniel Kade propose un reçu d’intention de délégation distinct du protocole : mandat initial, garde des clés, objet et effets de la tâche, fraîcheur de la révocation, décision du serveur de ressource et clôture.

Le pouvoir de signer le maillon suivant

Le problème de départ est familier aux architectures d’agents. Un orchestrateur obtient l’accès à plusieurs ressources, puis confie une partie du travail à un composant spécialisé. Lui remettre le jeton d’origine ou sa clé privée transmettrait trop de pouvoir. Lui demander un nouveau jeton au serveur d’autorisation pour chaque étape maintiendrait ce serveur au centre de chaque interaction.

La révision 03 choisit une troisième voie. Le serveur d’autorisation signe un Delegated Authorization Token racine et le lie à l’empreinte d’une clé contrôlée par le premier client. Celui-ci peut exercer l’autorisation ou signer un jeton enfant, lui-même lié à la clé du client délégué. Le processus peut se répéter tant que la profondeur restante le permet.

Chaque enfant expose dans son en-tête protégé la clé publique qui vérifie sa signature. Son empreinte RFC 7638 doit correspondre au cnf.jkt du parent. Le serveur de ressource remonte ainsi jusqu’à une racine dont la clé provient d’une configuration fiable ou de métadonnées authentifiées. Le dernier client ajoute une preuve DPoP qui lie sa clé, la requête et la sérialisation exacte de toute la chaîne.

Le résultat est plus précis qu’un récit organisationnel. Il prouve que la clé désignée au maillon précédent a signé le suivant et que le dernier demandeur possède la clé attendue. La chaîne n’est pas un bearer token ; le projet propose le schéma HTTP DA et interdit de la traiter comme un jeton Bearer ordinaire.

Réduire une permission exige une sémantique

La propriété centrale est monotone : un enfant ne peut élargir ni les permissions, ni les audiences, ni la fenêtre de validité, ni la capacité de déléguer encore. Pour scope, la comparaison ressemble à une inclusion d’ensembles. Un terme absent de l’autorisation effective du parent ne peut apparaître chez l’enfant. Omettre scope supprime cette composante ; l’omission ne la fait pas réapparaître par défaut.

Avec authorization_details, l’exercice est nettement moins mécanique. Un objet peut contenir une limite de montant, un identifiant de ressource, une liste d’actions, une valeur par défaut ou un joker. Un JSON plus court peut donner davantage de pouvoir si une omission active une valeur large. Le texte demande donc à chaque type de définir une procédure déterministe permettant de conclure qu’une valeur enfant est bien contenue dans la valeur effective du parent.

Comparer les octets ou seulement le champ type ne suffit pas. Si le vérificateur ne connaît pas la règle de containment, il doit rejeter la chaîne. Une extension qui modifie l’autorisation obéit à la même discipline : elle ne peut servir de restriction que si tous les vérificateurs prévus savent la traiter. Une contrainte décorative, ignorée par le serveur de ressource, ne doit pas fabriquer une fausse impression de moindre pouvoir.

Cette exigence déplace une part de la gouvernance vers les vocabulaires. La signature garantit l’intégrité de la valeur. Seule la spécification du type explique si cette valeur est réellement plus étroite. Deux implémentations qui interprètent différemment un défaut ou un joker peuvent valider la même cryptographie et calculer deux autorités effectives différentes.

La profondeur ne mesure pas le risque

Chaque racine contient un max_delegation_depth fini. Une valeur zéro interdit tout enfant valide. À partir d’une valeur positive m, l’enfant peut annoncer une valeur comprise entre zéro et m-1 ; s’il l’omet, il reçoit m-1. Le serveur d’autorisation fixe en outre une limite de déploiement.

Ce nombre borne le nombre d’arêtes futures, pas leur conséquence. Une unique délégation terminale peut autoriser une opération irréversible. Plusieurs maillons peuvent aboutir à une simple lecture. Profondeur zéro ne veut dire ni « faible risque », ni « client vu par l’utilisateur », ni « transaction approuvée ».

Pour un flux impliquant un resource owner, le projet exige que la décision initiale couvre la capacité du client à émettre ultérieurement des jetons enfants sans nouvelle interaction, ainsi que la profondeur maximale. Une autorisation d’accès ordinaire ne peut pas être réinterprétée en autorisation de déléguer. C’est une séparation essentielle.

Le projet laisse toutefois à l’authorization server la manière de présenter cette capacité. Il recommande d’expliquer que les délégations suivantes pourront échapper à son observation et à celle du propriétaire. Mais « autoriser deux niveaux » reste une description abstraite. Elle ne dit pas quels prestataires apparaîtront, quelle clé sera découverte hors bande, quelles tâches leur seront confiées ni quels effets une permission autorise réellement.

L’intention se trouve là où le projet ne prétend pas la mettre

Le périmètre exclut explicitement la découverte de la clé d’un autre client, la négociation hors bande, la liaison d’une chaîne remise à une requête ou à une tâche précise, la comparaison propre à chaque type et la distribution de l’état de révocation. Ces exclusions empêchent justement de lire le jeton comme un ordre de mission complet.

Prenons un agent de recherche recevant dix minutes de lecture sur une API documentaire, sans droit de déléguer. La chaîne peut être parfaite. Elle ne distingue pas pour autant « résumer le dossier approuvé » de « explorer tous les dossiers accessibles ». Cette distinction vient de la requête, de la politique applicative et du contexte de la tâche. Même une réponse d’autorisation positive ne prouve pas que le travail a réussi ni que les données obtenues n’ont pas alimenté une décision ultérieure.

Le texte le formule à sa manière : valider la chaîne ne suffit pas à autoriser une requête de ressource. Le serveur doit encore vérifier DPoP, la liaison à la requête, l’audience et les permissions applicatives. Cette décision est un autre événement, tenu par un autre acteur.

Une politique sérieuse ne demande donc pas au protocole de porter une intention universelle. Elle conserve l’intention minimale à côté du protocole et relie les deux par des empreintes sûres.

La révocation a une heure d’écriture et une heure d’effet

Révoquer la racine invalide toutes les chaînes qui en dépendent. Révoquer un enfant invalide les chaînes qui le contiennent et tous ses descendants, mais pas son parent ni ses frères. Le serveur d’autorisation doit reconnaître une cible par une identité non ambiguë, par exemple l’empreinte résistante aux collisions de sa sérialisation exacte.

La réussite de l’appel de révocation n’est pourtant qu’une écriture chez l’authorization server. Un resource server qui valide hors ligne n’apprend pas cet état par magie. La révision 03 ne définit aucun canal de distribution. Les durées courtes limitent l’exposition, sans prouver à quel moment chaque serveur a cessé d’accepter la chaîne.

L’audit doit donc retenir deux instants : quand la révocation a été enregistrée et quelle version de cet état le serveur de ressource avait reçue au moment de sa décision. Sans cette seconde preuve, on ne sait pas si une chaîne administrativement morte était encore techniquement recevable dans ce point du système.

La mise en cache ne supprime pas ce devoir. Les signatures et restrictions effectives peuvent être mémorisées à partir de l’empreinte de la chaîne, mais l’entrée doit suivre l’expiration, l’état des clés, la politique locale et les informations de révocation disponibles. La fraîcheur DPoP et la détection de replay restent propres à chaque requête.

Visibilité réduite au centre, accrue à la périphérie

La délégation locale protège une forme de confidentialité. Le serveur d’autorisation n’a pas besoin de connaître chaque client délégué, chaque ressource aval ni chaque horaire d’accès. Il n’est plus un observateur obligatoire de toute la topologie opérationnelle.

En revanche, le serveur de ressource voit la chaîne ordonnée complète. Elle peut révéler l’émetteur, le sujet, les relations entre clients, les audiences, les permissions et la structure du workflow. Des empreintes de clé stables ou des identifiants persistants facilitent aussi la corrélation. Le gain de confidentialité dépend donc du point d’observation ; il n’est pas global.

Le projet recommande des événements d’audit pour l’émission de la racine, la délégation locale, le résultat de validation, l’autorité effective et la décision de ressource. Il déconseille de journaliser les credentials complets. Une empreinte à sens unique de la chaîne permet de rapprocher les événements, tandis que les en-têtes Authorization et DPoP restent expurgés et que les détails sensibles sont protégés.

Un reçu d’intention de délégation

Je propose un reçu d’intention de délégation. C’est un dispositif de gouvernance de Daniel Kade, pas une exigence du projet et pas un nouveau claim OAuth.

Au départ, le reçu fixe l’empreinte de l’événement d’autorisation et de la version de présentation du consentement, l’émetteur et ses métadonnées fiables, les permissions effectives, les audiences, la durée, la capacité de déléguer et la profondeur. Aucun token, secret, en-tête brut ou identifiant de sujet inutile n’y figure.

Pour chaque saut local, il lie l’empreinte de chaîne, les empreintes publiques parent et enfant, les restrictions avant et après, la version de la règle de containment, le service de signature et la preuve minimale du choix du client. Il signale la réutilisation d’une clé et le besoin éventuel d’un parent unique.

Le reçu ajoute ensuite le morceau absent du credential : une empreinte de la tâche concrète, du résultat acceptable et de la frontière d’effet ; le responsable de la décision ; les limites d’environnement ou de transaction ; les conditions imposant une nouvelle interaction humaine. Il protège le contenu de la tâche au lieu de le recopier.

Au moment de la ressource, il conserve la politique appliquée, la fraîcheur de l’état de révocation reçu, le résultat DPoP, l’autorité calculée et la décision finale. La clôture constate la classe d’opération observée, la réussite ou l’échec, les effets secondaires matériels et la référence de retour arrière ou d’incident.

Ce reçu ne prétend pas améliorer la cryptographie. Il empêche simplement « cette clé pouvait réduire et exercer ce pouvoir » de devenir « une personne voulait nécessairement cet effet ». Le minimum utile tient en cinq éléments : mandat racine, empreinte du saut, objet et effet, fraîcheur de révocation, décision observée.

Ce que la chaîne mérite de prouver

La révision 03 demeure un Internet-Draft individuel. Elle n’est ni un texte adopté par l’OAuth WG, ni un consensus IETF, ni un RFC ; les inscriptions IANA qu’elle demande ne sont pas encore des registres actifs. Aucun déploiement ne peut être déduit de sa précision.

Dans cette limite, sa contribution est substantielle. Elle permet de vérifier que l’autorité a suivi une lignée de clés et n’a pas grandi. Elle oblige les vocabulaires applicatifs à expliciter leurs règles de réduction. Elle sépare correctement la possession de la chaîne de la possession de la clé terminale et reconnaît le trou de distribution de la révocation.

La faute serait de faire dire à ce résultat davantage. Une chaîne valide prouve une délégation cryptographiquement autorisée sous des contraintes calculées. Elle ne prouve pas le motif humain, la qualité de la présentation initiale, la fraîcheur de tous les observateurs ni l’effet final.

Une fois des données révélées ou une infrastructure modifiée, une intention absente ne peut pas être reconstituée par une signature ultérieure. L’autorité doit rester dans la chaîne. L’intention doit être conservée à ses côtés, avant l’effet.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. OAuth 2.0 Delegated Authorization, révision 03
  5. Fiche Datatracker du projet
  6. Historique du projet Delegated Authorization
  7. Charte du groupe OAuth
  8. RFC 6749 : cadre OAuth 2.0
  9. RFC 7009 : révocation de jetons OAuth 2.0
  10. RFC 7638 : empreinte de clé JWK
  11. RFC 8414 : métadonnées du serveur d’autorisation
  12. RFC 8707 : indicateurs de ressource pour OAuth 2.0
  13. RFC 8725 : bonnes pratiques JWT
  14. RFC 9396 : requêtes d’autorisation riches
  15. RFC 9449 : démonstration de possession DPoP
  16. RFC 9700 : bonnes pratiques de sécurité OAuth 2.0
  17. RFC 9728 : métadonnées de ressource protégée OAuth 2.0