Résumé

  • La révision 01 de draft-zehavi-oauth-authz-req-del-chain, annoncée le 10 septembre 2026, reste une contribution individuelle : ce n’est ni un texte adopté par le groupe OAuth, ni un RFC.
  • Des signatures JWS détachées, des empreintes du maillon précédent, des positions et la continuité des destinataires rendent détectables les modifications au sein du chemin visible.
  • Une coupe en fin ou au milieu rompt ces contrôles. Une coupe en tête peut être suivie d’une nouvelle chaîne parfaitement valide commençant chez le courtier.
  • Le serveur doit donc décider localement si le premier émetteur visible est autorisé pour ce client, cette ressource et ce contexte.

La première case n’est pas forcément le premier fait

Un serveur d’autorisation remonte une chaîne depuis son dernier maillon. Il vérifie que celui-ci lui est bien destiné, que son émetteur correspond au client OAuth authentifié, puis contrôle chaque signature, numéro, empreinte et passage d’un destinataire à l’émetteur suivant. Tout peut réussir.

Le résultat signifie que l’objet reçu est cohérent. Il ne signifie pas que l’objet commence assez tôt.

Le projet OAuth Authorization Request Delegation Chain vise les demandes d’autorisation redirigées par plusieurs intermédiaires. Un courtier joue le rôle de serveur d’autorisation pour sa partie aval et celui de client OAuth envers le serveur suivant. Le serveur terminal, qui recueille le consentement et délivre les jetons, peut ne connaître directement que le dernier courtier.

Le profil proposé place dans authorization_details, selon le modèle RAR, une suite ordonnée de nœuds JSON. Chaque nœud nomme l’entité qui atteste, son destinataire, sa position et le client attesté. Une JWS détachée couvre sa représentation déterministe. p_hash reprend l’empreinte de l’événement signé précédent.

Cette construction donne une excellente réponse à la question « le chemin que je vois a-t-il été remanié ? ». Elle ne transforme pas la première position déclarée en certificat historique.

La coupure de tête ne casse pas la chaîne neuve

La révision 01 décrit trois formes de troncature. Supprimer la fin conduit la chaîne à se terminer sur un destinataire autre que le serveur récepteur. Retirer un maillon central rompt l’empreinte enregistrée par son successeur et la continuité entre audience et émetteur.

En revanche, un courtier peut abandonner le contexte antérieur et fabriquer une nouvelle chaîne dont il devient chain[0], avec une empreinte précédente nulle. Les signatures produites à partir de là sont authentiques et les liens sont réguliers. Le texte appelle cette opération re-origination.

Le brouillon ne dissimule pas cette limite : il dit que la validation cryptographique prouve l’intégrité de la chaîne visible, mais pas l’absence d’un contexte avant son premier nœud. Il impose alors au serveur récepteur d’appliquer une politique locale. Celle-ci doit dire quels émetteurs peuvent apparaître en tête pour une catégorie de client, une ressource et un déploiement donnés.

Il faut aussi séparer intégrité et autorité. Une signature valable établit qu’un émetteur a signé ; elle ne lui confère pas le droit de représenter une délégation. Le nouveau champ de métadonnées client_roles peut annoncer oauth_broker, mais une valeur auto-déclarée ne constitue pas une preuve de confiance. L’authentification du client immédiat reste obligatoire.

Une dégradation nommée n’efface pas une origine omise

La révision ajoute la découverte du support par les métadonnées RFC 8414. Elle prévoit aussi le cas où le serveur amont suivant ne comprend pas le type oauth_request_delegation_chain.

Le courtier ne doit pas faire disparaître silencieusement une chaîne déjà présente. Il doit refuser l’opération, préserver le contexte par un autre mécanisme de confiance ou transmettre sans chaîne seulement si la politique locale et la chaîne signée l’autorisent. omit_chain vaut allowed ou forbidden; l’absence du champ signifie forbidden, et tous les nœuds validés doivent consentir à l’omission.

Ce choix rend visible une perte de preuve à l’étape suivante. Il ne renseigne pas le passé du premier nœud. La permission d’abandonner une chaîne connue et l’autorisation d’en recréer une après un contexte inconnu sont deux décisions distinctes.

La demande d’enregistrement IANA de client_roles appartient elle aussi au projet. À ce stade, Datatracker classe le document parmi les Internet-Drafts individuels actifs, sans adoption par le groupe, RFC, déploiement ni incident établi.

Sources