Résumé

  • draft-li-oauth-delegated-authorization-03 propose qu’un serveur d’autorisation émette une racine liée à une clé, puis qu’un client puisse signer un jeton enfant plus étroit pour un autre client. Le texte reste un Internet-Draft individuel à visée Standards Track, non un RFC ni une preuve de déploiement.
  • La signature de l’enfant établit que la clé désignée par le parent a produit cet enfant. Elle ne remplace ni la confiance dans la racine, ni le contrôle des réductions cumulées, ni le consentement distinct à déléguer.
  • Le détenteur de la feuille présente la chaîne ordonnée exacte et une preuve DPoP. Le serveur de ressources vérifie encore tous les maillons, l’état de révocation et sa propre politique avant d’autoriser l’effet demandé.

Dans une enquête, le jeton enfant est souvent le premier objet que l’on voit. Il porte une signature valide, un public correct et une durée encore ouverte. Cette vue par la fin produit une conclusion trompeuse : l’objet paraît autorisé parce qu’il est cryptographiquement cohérent. Or son autorité n’existe qu’en remontant la chaîne.

Le projet individuel draft-li-oauth-delegated-authorization-03 construit précisément cette dépendance. Le serveur d’autorisation émet un jeton racine et lie son pouvoir à la clé du client A par cnf.jkt. Si la profondeur restante le permet, A signe un enfant lié à la clé de B. B peut déléguer à son tour, mais seulement dans l’enveloppe cumulative qui lui est parvenue.

L’intérêt est évident pour des agents et des services qui ne veulent pas rappeler le serveur d’autorisation à chaque étape. L’absence de ce serveur au moment de l’émission de l’enfant n’est pourtant pas une autorité nouvelle. La racine avait autorisé, en plus de l’accès, une capacité bornée de nommer des délégués. Chaque intermédiaire consomme une partie de cette capacité et ne peut l’agrandir.

La révision 03 date du 24 juillet 2026 et expire le 25 janvier 2027. Son en-tête annonce une intention Standards Track, tandis que l’API Datatracker ne renseigne encore ni flux ni niveau prévu. Les demandes d’enregistrement figurant dans le texte ne sont pas des inscriptions IANA acquises. Il faut donc parler d’un mécanisme proposé, sans lui attribuer consensus, interopérabilité ou usage réel.

La première clé ne vient pas du jeton

La racine est vérifiée avec une clé du serveur d’autorisation obtenue par configuration de confiance ou métadonnées authentifiées. Le vérificateur ne peut pas lire iss, accepter une JWK offerte par le même objet et déclarer la racine sûre. L’ancre initiale vient de l’extérieur de la chaîne.

Chaque enfant contient ensuite, dans son en-tête protégé, la clé publique de celui qui l’a signé. Son empreinte RFC 7638 doit être égale au cnf.jkt du parent immédiat. La signature prouve donc que le détenteur de la clé autorisée par le parent a produit le maillon suivant.

Cette continuité ne dit pas à quelle société, machine ou instance appartient la clé. Le moyen par lequel A obtient la clé publique de B et l’associe au bon délégué est hors du périmètre du projet. Une configuration, un runtime d’agent ou un protocole applicatif doit fournir ce fait. La chaîne peut préserver parfaitement une erreur d’association commise en amont.

Il faut donc conserver deux reçus. Le reçu de continuité établit l’égalité d’empreinte et la signature. Le reçu d’association indique l’instance, le tenant, le propriétaire, le canal et la raison pour laquelle cette clé représentait le délégué attendu. Les fusionner rend le point non normalisé invisible.

Le premier élément doit être la racine. Le vérificateur ne cherche pas plus loin un jeton susceptible de sauver un préfixe invalide. L’ordre est une propriété d’autorité, non un simple format de transport.

« Plus étroit » doit pouvoir être calculé

Le principe central est monotone : un enfant ne peut augmenter l’autorisation effective du parent. Pour scope, l’inclusion d’ensembles donne une règle reproductible. Pour authorization_details, il faut connaître la sémantique du type : ressources, actions, valeurs par défaut, jokers, tableaux et membres omis.

Comparer le JSON brut ne suffit pas. Un objet plus court peut être plus large si l’absence d’un champ signifie « tous ». Deux objets qui partagent un type peuvent viser des comptes distincts. Une bibliothèque qui ignore ce sens ne doit pas improviser. La révision 03 lui impose de rejeter la chaîne lorsqu’elle ne peut démontrer le sous-ensemble.

L’omission a elle-même une conséquence. Si un enfant omet scope ou authorization_details, ce composant disparaît et ne peut réapparaître chez un descendant. L’omission de aud conserve au contraire l’audience effective du parent. L’omission de nbf n’ajoute pas de nouvelle date minimale. Toute extension future doit dire si elle est héritée, réintroduite, réduite ou supprimée.

Cette rigueur rejoint la doctrine de docs/heng-lu-note.md. La couche commune doit rester déterministe et localement vérifiable. Un service central ne devrait pas devenir l’interprète permanent de revendications nouvelles. Sans règle de contenance explicite, l’échec fermé protège mieux l’autonomie des serveurs de ressources qu’une équivalence supposée.

Le calcul part de la racine et traverse chaque maillon. Valider séparément chaque JWT puis regarder seulement la feuille perd les effets d’omission et de composition. Le reçu utile contient le chemin et les restrictions effectives calculées, pas seulement le dernier objet.

La profondeur ne mesure pas tout le rayon d’explosion

Chaque racine comporte max_delegation_depth. Avec une profondeur effective m, l’enfant explicite choisit une valeur comprise entre zéro et m-1; s’il l’omet, la valeur devient m-1. Une feuille à zéro peut utiliser son autorisation, mais ne peut plus la transmettre.

Cette limite borne la longueur d’un chemin. Elle ne borne pas le nombre de frères, le volume total d’actions ni la valeur économique d’une permission. Un client à profondeur trois peut créer de nombreux enfants. Une permission très étroite en vocabulaire peut commander un compte critique. Une durée courte peut suffire à une opération irréversible.

Le projet exige donc aussi des limites de taille, de nombre de jetons et de coût de vérification. Une exploitation sérieuse doit ajouter la maîtrise du fan-out, l’inventaire des descendants et une durée adaptée à la tâche. Le serveur d’autorisation ne voit pas nécessairement les émissions locales ; il ne peut pas reconstruire par magie le graphe qu’on lui a choisi de ne pas soumettre.

Cette décentralisation réduit la latence et la dépendance centrale. Elle supprime aussi un point naturel d’observation. Si l’organisation veut retrouver tous les descendants d’une clé compromise, elle doit construire un plan de reçus ou de journaux. Ce plan est un engagement opérationnel supplémentaire, non une propriété apportée par la signature.

Accepter l’accès ne signifie pas accepter la nomination

Le projet exige que le serveur d’autorisation distingue le consentement à l’accès du consentement à la délégation locale. Autoriser A à lire un rapport n’autorise pas automatiquement A à choisir d’autres lecteurs. Le titulaire doit comprendre les permissions, audiences, durées et profondeur qu’il transfère, ainsi que le fait que chaque enfant ne sera pas revu par le serveur.

La racine lie donc un pouvoir d’usage et, éventuellement, un pouvoir de nomination. La même clé privée sert à prouver l’usage courant par DPoP et à signer un enfant. Une compromission élargit alors les possibilités de l’attaquant. Les interfaces de signature devraient séparer les formes admises afin qu’un oracle destiné aux preuves HTTP ne devienne pas un émetteur de jetons enfants.

Le détenteur de la racine ne peut pas présenter celle-ci comme l’approbation personnelle par le titulaire de B ou C. La racine autorise une enveloppe et une profondeur ; A choisit son cocontractant dans cette enveloppe et doit pouvoir justifier ce choix. Le serveur de ressources conserve enfin son veto au point d’effet.

On obtient trois autorités différentes : le serveur d’autorisation fixe le plafond transférable ; le délégant choisit un délégué et resserre le mandat ; le serveur de ressources applique l’état et la politique présents. Un produit qui les réduit à « token valid » transforme une chaîne de décisions en fiction unique.

La preuve de feuille couvre les octets exacts, pas leur légitimité

La chaîne proposée est sérialisée de la racine à la feuille, avec ~ entre JWT compacts. La preuve DPoP de la feuille calcule ath sur cette représentation exacte. Décoder, normaliser ou resérialiser avant le hachage change ce qui a été autorisé.

Cela empêche un observateur d’ajouter, retirer ou réordonner des maillons sans obtenir une nouvelle preuve de la clé feuille. Mais DPoP ne vérifie pas les signatures antérieures ni la réduction des droits. Il établit seulement que le détenteur de la feuille a présenté cette requête avec cette chaîne exacte.

La différence avec l’article BTW consacré à RFC 9449 est nette. Celui-ci conserve la contrainte de l’émetteur, la méthode, l’URI, la fraîcheur et le rejeu. Le présent article traite de la reconstruction de l’autorité cumulée avant que cette contrainte terminale devienne utile.

Un enfant n’embarque pas d’identifiant de parent. Avec une même clé de parent et des restrictions compatibles, il peut être valide dans une autre chaîne. L’usage d’une clé différente par jeton limite cette substituabilité. Si un déploiement veut lier un enfant à un parent unique, il lui faut des clés distinctes ou une restriction applicative dédiée.

La révocation doit voyager jusqu’au décideur

Le projet étend RFC 7009 : la requête de révocation envoie la chaîne exacte et vise son dernier élément. La clé liée à la cible, ou la clé du délégant direct pour un enfant, peut prouver le droit de révoquer. L’authentification OAuth ordinaire du client n’est pas à elle seule une autorisation de révocation.

Révoquer une racine invalide toutes ses chaînes. Révoquer un enfant invalide toute chaîne qui le contient et ses descendants, sans révoquer le parent, les frères ou un autre jeton lié à la même clé.

Le HTTP 200 de l’endpoint ne prouve pas que chaque serveur de ressources a reçu l’état. Le texte ne définit pas de distribution de révocation. Un vérificateur hors ligne peut continuer jusqu’à l’expiration ou jusqu’à une mise à jour externe. Les objectifs de révocation rapide nécessitent donc des durées courtes et un canal de statut en ligne ou promptement synchronisé.

Un reçu de révocation doit indiquer la cible exacte. Un reçu de distribution doit indiquer quel serveur a observé quelle version et quand. Un reçu applicatif doit montrer que les sessions ou dérivations ont été fermées. Aucun ne peut être déduit automatiquement des deux autres.

Le serveur de ressources garde la dernière décision

Une fois la chaîne et DPoP validés, le serveur applique encore audience, temps, permissions, état de ressource, règles de tenant, politique du titulaire et révocation. Une chaîne valide peut recevoir un refus. Ce refus n’est pas une panne cryptographique ; il est la fonction normale d’une autorité localisée.

La racine est un plafond, pas une commande distante. Chaque enfant abaisse ce plafond. Le serveur peut refuser davantage selon les faits qu’il connaît au moment de l’effet. Cette structure évite qu’une autorisation historique force l’exploitation malgré un compte gelé, une ressource déplacée ou une règle de risque nouvelle.

L’effet final reste séparé. Une décision d’accès réussie peut précéder un conflit de base, une file indisponible ou une action externe partielle. La détection de rejeu DPoP n’est pas une garantie « exactement une fois ». Il faut un identifiant de transaction, un reçu de commit et une réconciliation applicative.

Reçu Preuve minimale Ne prouve pas
Consentement racine Accès, délégation distincte, profondeur Approbation d’un enfant futur nommé
Émission racine Émetteur, hachage, droits, audience, temps, clé Accès actuel
Association du délégué Instance, tenant, empreinte, canal Réduction correcte
Émission enfant Parent, enfant, limites, profondeur restante Racine fiable ou statut actuel
Validation chaîne Signatures, continuités, contenance, temps Possession de la feuille
Preuve feuille Méthode, URI, ath, nonce, rejeu Légitimité des ancêtres
Statut État des ancêtres et fraîcheur Livraison à tous les décideurs
Autorisation locale Politique, opération, décision Commit applicatif
Effet Transaction et état durable Résultat externe souhaité
Réconciliation Observation et exceptions Autorité pour agir encore

La phrase de gouvernance tient en une ligne : le jeton enfant est bien signé, mais son pouvoir n’existe que si toute la chaîne l’a conservé et si le serveur de ressources l’accepte encore.