OAuth 2.0 Delegated Authorization#

Ruochen Li, Haiguang Wang, Chunchi Peter Liu, Tieyan Li (Huawei) — individual draft

• Why: Down-scoping in OAuth today requires token exchange (RFC 8693) round-trips through the authorization server; this draft proposes client-local delegation with key-bound token chains — relevant to service chains and to how agentic clients might delegate constrained authority without AS involvement at each step.
• What: Delegation Tokens (DTs) issued by the AS and bound to the client's key; the client locally issues Delegated Access Tokens (DATs) bound to a delegate's key. Only DATs are accepted at resource servers — DTs are never used as access tokens. The RS validates the ordered token chain, the restrictions imposed at each delegation step, and a DPoP proof signed by the key bound to the leaf token.
• How: A digitally signature-linked chain analogous to PKI certificates; the explicit contrast with RFC 8693: no external STS involved, subordinate tokens tightly linked to their superior, delegation can occur at any node along the invocation chain including third-party intermediaries. Supports Rich Authorization Request details, encrypted (JWE) DTs, and sign-then-encrypt DATs; future work covers multi-layer delegation and multiple DTs per request.
• Where applicable: Service-to-service and delegation chains. Early individual draft from Huawei, seeking feedback. Note: the slides the agenda links to this slot actually cover a different draft (Nick Watson/Google's refresh-token and authorization-expiration parameters, also seeking adoption); the Delegated Authorization deck was presented under the OAuth 2.1 slot — the write-up above uses that deck.