oauth R. Li Internet-Draft H. Wang Intended status: Informational Huawei Int. Pte Ltd Expires: 7 January 2027 C. Liu Huawei Technologies T. Li Huawei Int. Pte Ltd 6 July 2026 OAuth 2.0 Delegated Authorization draft-li-oauth-delegated-authorization-02 Abstract Delegated authorization enables a client to delegate a subset of its granted privileges to a subordinate access token (also known as a delegated access token). This mechanism allows the client to securely delegate authorization to another application while maintaining fine-grained control over delegated permissions. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://liuchunchi.github.io/li-oauth-delegated-authorization/draft- li-oauth-delegated-authorization.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-li- oauth-delegated-authorization/. Discussion of this document takes place on the WG Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://datatracker.ietf.org/wg/oauth/about/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Source for this draft and an issue tracker can be found at https://github.com/liuchunchi/li-oauth-delegated-authorization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Li, et al. Expires 7 January 2027 [Page 1] Internet-Draft Delegated-Auth July 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Protected Resource Metadata Discovery . . . . . . . . . . . . 7 5.1. The delegated_resources Metadata Field . . . . . . . . . 8 5.2. The authorization_requirements Metadata Field . . . . . . 8 5.3. Metadata Example . . . . . . . . . . . . . . . . . . . . 10 6. Delegation Tokens and Delegated Access Tokens . . . . . . . . 12 6.1. Delegation Tokens . . . . . . . . . . . . . . . . . . . . 12 6.1.1. Top Level Delegation Token . . . . . . . . . . . . . 13 6.2. Delegated Access Tokens . . . . . . . . . . . . . . . . . 14 7. Acquiring Delegation Tokens . . . . . . . . . . . . . . . . . 14 7.1. Authorization Code Grant . . . . . . . . . . . . . . . . 14 7.2. Other Grant Types . . . . . . . . . . . . . . . . . . . . 15 8. Creating Delegated Access Tokens . . . . . . . . . . . . . . 15 9. Using Delegated Access Tokens . . . . . . . . . . . . . . . . 16 10. Verification of Delegated Access Tokens . . . . . . . . . . . 16 10.1. Local Verification . . . . . . . . . . . . . . . . . . . 16 10.2. Token Introspection . . . . . . . . . . . . . . . . . . 17 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 11.1. Privacy Benefits . . . . . . . . . . . . . . . . . . . . 17 11.2. Relationship to Token Exchange . . . . . . . . . . . . . 18 11.3. Trade-offs . . . . . . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 Li, et al. Expires 7 January 2027 [Page 2] Internet-Draft Delegated-Auth July 2026 13. Operational Considerations . . . . . . . . . . . . . . . . . 19 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 14.1. OAuth Parameters Registry . . . . . . . . . . . . . . . 20 14.2. OAuth Access Token Types Registry . . . . . . . . . . . 20 14.3. HTTP Field Name Registry . . . . . . . . . . . . . . . . 20 14.4. OAuth Protected Resource Metadata Registry . . . . . . . 21 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 15.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Token Format . . . . . . . . . . . . . . . . . . . . 24 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 24 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Integration with Step-Up Authorization . . . . . . . 27 Appendix C. Use Cases . . . . . . . . . . . . . . . . . . . . . 28 C.1. Delegating Subset of Access Rights to Specialized AI Agents . . . . . . . . . . . . . . . . . . . . . . . . . 28 C.2. Third-Party Analytics Platform Integrated in an Enterprise SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction OAuth 2.0 [RFC6749] provides a framework for authorizing third-party applications to access protected resources on behalf of a resource owner. However, in existing implementations, access tokens issued to clients often contain excessive permissions that exceed actual requirements, creating security vulnerabilities and potential data exposure risks. This specification extends OAuth 2.0 with a delegated authorization framework that enables clients to create subordinate access tokens with restricted permissions. This approach addresses the problem of over-privileged access tokens by implementing a token-chain architecture that decouples the initial authorization from the final resource access, allowing delegated tokens to be created and used flexibly. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Li, et al. Expires 7 January 2027 [Page 3] Internet-Draft Delegated-Auth July 2026 3. Terminology This specification uses the following terms defined in OAuth 2.0 [RFC6749]: authorization server, client, resource server, and resource owner. A resource server can also act as a client when it accesses one or more downstream resource servers. This document refers to such an entity as an intermediary resource server: it is downstream from the client that invokes it, and acts as a client when making requests to resource servers that are farther downstream in the call chain. Intermediary resource servers can be chained. The following additional terms are used throughout this document: *Intermediary Resource Server*: A resource server that receives a request from a client and, to serve that request, acts as an OAuth client when accessing one or more downstream resource servers. It is downstream from its caller and upstream from the resource servers it invokes. A downstream resource server can itself be an intermediary resource server when it invokes another resource server farther downstream in the call chain. *Target Resource Server*: The resource server that receives a delegated access token from an upstream intermediary resource server for a particular downstream request and hosts the protected resource requested in that hop. This role is relative to a particular request: a target resource server for one hop can also act as an intermediary resource server for a subsequent downstream hop. It is downstream from the intermediary resource servers that precede it in that call chain. *Delegation Token*: A token issued by the authorization server for the client that enables the client to create delegated access tokens. *Delegated Access Token*: A token created by the client using the delegation token, with permissions being a subset of the delegation token's privileges and a more limited lifespan. *Delegation Key*: A cryptographic key bound to the delegation token, used by the client to sign delegated access tokens. The delegation key is presented in the token request as the delegation_key parameter. Li, et al. Expires 7 January 2027 [Page 4] Internet-Draft Delegated-Auth July 2026 4. Overview The delegated authorization framework introduces a hierarchical token structure where a client can obtain a delegation token from an authorization server and use it to issue subordinate access tokens with reduced permissions. This enables fine-grained access control while maintaining the security properties of the original authorization grant. Li, et al. Expires 7 January 2027 [Page 5] Internet-Draft Delegated-Auth July 2026 +-----------+ 1. Authorization +---------------+ | | Request | | | +----------------------> | | | | Resource | | | 2. Authorization | Owner | | | Grant | | | <----------------------+ | | | +---------------+ | Client | | | 3. Authorization +---------------+ | | Grant | | | +----------------------> | | | | Authorization | | | 4. Delegation | Server | | | Token | | | <----------------------+ | +--^-----+--+ +---------------+ | |5. Delegated 6. Delegated | | Access Resource| | Token | | +------+-----v-----+ 5. Delegated +---------------+ | | Access Token | | | Intermediary +------------------->| Downstream / | | Resource Server | | Target | | | 6. Target | Resource | | | Protected | Server(s) | | | Resource | | | <--------------------+ | +------------------+ +-------+-------+ | | Optional subsequent | downstream request v +---------------+ | Downstream / | | Target | | Resource | | Server | +---------------+ Figure 1: Delegated Authorization Framework Architecture 1. The client requests authorization from the resource owner. The client indicates in the authorization request that the requested authorization grant is for delegated authorization. 2. The client receives an authorization grant. Li, et al. Expires 7 January 2027 [Page 6] Internet-Draft Delegated-Auth July 2026 3. The client requests a delegation token by authenticating with the authorization server and presenting the authorization grant and its delegation key as defined in Section 3. 4. The authorization server authenticates the client and validates the authorization grant, and if valid, issues a delegation token. 5. The client calls an intermediary resource server's API, presenting the delegated access token generated from the delegation token. The delegated access token is issued by the client using the delegation key. The intermediary resource server can request protected resources from one or more downstream resource servers by presenting the delegated access token. A downstream resource server can itself be an intermediary resource server for a subsequent downstream request. 6. A target resource server for a downstream request validates the delegated access token, and if valid, serves the resource. Responses propagate back through the intermediary resource servers, each of which can optionally transform a downstream response into a service-specific response, and ultimately return a response to the client. Both delegation token and delegated access token can be JSON Web Tokens (JWTs) [RFC7519] or CBOR Web Tokens (CWTs) [RFC8392]. 5. Protected Resource Metadata Discovery Before the client retrieves a delegation token and generates a delegated access token for an intermediary resource server, the client needs to determine the permissions required by that resource server for its own protected resources, the permissions required when accessing downstream resource servers, and the identity of those downstream resource servers. Such information can be manually configured into the client, or it can be dynamically discovered using OAuth 2.0 Protected Resource Metadata [RFC9728]. Each resource server publishes its metadata at the standard well- known URI as defined in [RFC9728]. The metadata describes the resource server as a protected resource. A client can determine that a resource server is an intermediary resource server when the metadata contains the delegated_resources key. The delegated_resources metadata field identifies any downstream resource servers the publishing resource server accesses and the authorization capabilities for each. If a downstream resource server is itself an intermediary resource server, the client can also retrieve that resource server's metadata to discover subsequent downstream requirements. Li, et al. Expires 7 January 2027 [Page 7] Internet-Draft Delegated-Auth July 2026 The authorization_requirements metadata field identifies the authorization requirements for specific endpoints or operations. A client can use this field to request a delegation token and create delegated access tokens with the minimum permissions needed for the intended request. Discovery of protected resource metadata, including use of the WWW-Authenticate resource_metadata parameter, follows [RFC9728]. 5.1. The delegated_resources Metadata Field This specification defines a new protected resource metadata field, delegated_resources, that indicates the downstream resource servers and the authorization capabilities the publishing resource server needs for each. *delegated_resources*: JSON object mapping downstream protected resource identifiers (as defined in [RFC9728]) to the authorization capabilities for each. Each downstream resource value is a JSON object containing the following members: *authorization_target*: OPTIONAL. String identifying the protected resource to which the listed scopes_supported or authorization_details_types_supported apply. The value self indicates the downstream protected resource identified by the corresponding delegated_resources key. Any other value is a protected resource identifier as defined in [RFC9728]. If omitted, the default value is self. *scopes_supported*: OPTIONAL. JSON array of scope values [RFC6749] that the publishing resource server may need at the authorization_target. *authorization_details_types_supported*: OPTIONAL. JSON array of authorization details types [RFC9396] that the publishing resource server may need at the authorization_target. A downstream resource value MUST contain at least one of scopes_supported or authorization_details_types_supported. 5.2. The authorization_requirements Metadata Field This specification defines a new protected resource metadata field, authorization_requirements, that indicates the authorization requirements for specific endpoints or operations of the publishing resource server. The requirements can describe permissions needed at the publishing resource server itself, permissions delegated to downstream resource servers, or both. Li, et al. Expires 7 January 2027 [Page 8] Internet-Draft Delegated-Auth July 2026 *authorization_requirements*: JSON array of authorization requirement objects. Each object describes one endpoint or operation and the permissions required to access it. The following members are defined: *methods*: OPTIONAL. JSON array of HTTP methods to which this requirement applies. If omitted, the requirement applies independent of HTTP method. *path*: OPTIONAL. Absolute path or path template identifying the endpoint to which this requirement applies. If omitted, the requirement applies to the operation as otherwise identified by the object. *operation*: OPTIONAL. String identifying an application-level operation to which this requirement applies. This member is intended for APIs where the authorization requirement is associated with a named action rather than only with an HTTP path. The syntax and semantics of the operation identifier are deployment specific. For HTTP APIs where the method and path uniquely identify the protected action, methods and path are preferred. *scopes*: OPTIONAL. JSON array of scope values [RFC6749] required for the identified endpoint or operation at the publishing resource server. *authorization_details_types*: OPTIONAL. JSON array of authorization details types [RFC9396] required or accepted for the identified endpoint or operation at the publishing resource server. *authorization_details*: OPTIONAL. JSON array of authorization detail objects [RFC9396] that describe the required permissions for the identified endpoint or operation at the publishing resource server. This member can be used when the authorization details type alone is not sufficient to describe the minimum required permission. *delegated_resources*: OPTIONAL. JSON object mapping downstream Li, et al. Expires 7 January 2027 [Page 9] Internet-Draft Delegated-Auth July 2026 protected resource identifiers to delegated authorization requirement objects. This member describes permissions that the publishing resource server needs to receive in a delegated access token in order to call the specified downstream resource servers while serving the identified local endpoint or operation. Each delegated authorization requirement object MAY contain authorization_target, with the same semantics as in the delegated_resources metadata field, and identifies required permissions using scopes, authorization_details_types, or authorization_details. A top-level authorization requirement object MUST identify an endpoint or operation using path, operation, or both. Each top-level authorization requirement object MUST contain at least one of scopes, authorization_details_types, authorization_details, or delegated_resources. Each delegated authorization requirement object MUST contain at least one of scopes, authorization_details_types, or authorization_details. The authorization_requirements field is optional. Resource servers MAY omit it when authorization requirements are dynamic, confidential, or better conveyed through an authorization challenge. When both path and operation are present, path identifies the endpoint and operation further identifies the action within that endpoint. The authorization_requirements metadata is self-declared discovery information. It does not replace access control enforcement by resource servers, and clients MUST NOT assume that possession of the indicated permissions guarantees access to the identified endpoint or operation. 5.3. Metadata Example The following is a non-normative example of a resource server publishing protected resource metadata that describes both its downstream resource server capabilities and endpoint-specific authorization requirements: Li, et al. Expires 7 January 2027 [Page 10] Internet-Draft Delegated-Auth July 2026 { "resource": "https://analytics.example.com", "scopes_supported": ["openid", "analytics:summary"], "authorization_servers": ["https://idp.example.com"], "delegated_resources": { "https://crm.example.com": { "authorization_target": "self", "scopes_supported": ["read:contacts", "read:reports"], "authorization_details_types_supported": ["data"] } }, "authorization_requirements": [ { "methods": ["GET"], "path": "/summary", "scopes": ["analytics:summary"] }, { "methods": ["GET"], "path": "/reports/contacts", "delegated_resources": { "https://crm.example.com": { "scopes": ["read:contacts"], "authorization_details_types": ["data"] } } }, { "methods": ["GET"], "path": "/reports/monthly", "delegated_resources": { "https://crm.example.com": { "authorization_target": "https://reports.example.com", "scopes": ["read:reports"] } } } ] } In this example the resource server (https://analytics.example.com) indicates that it supports its own analytics:summary scope and that it may need access to the CRM resource server (https://crm.example.com) with the read:contacts and read:reports scopes. The authorization_requirements field further indicates that GET /summary requires the local analytics:summary scope, GET Li, et al. Expires 7 January 2027 [Page 11] Internet-Draft Delegated-Auth July 2026 /reports/contacts requires a delegated access token that covers the CRM read:contacts scope and data-type authorization details, and GET /reports/monthly requires a delegated access token presented to CRM that covers the read:reports scope at https://reports.example.com. The client uses this information, and optionally the metadata of downstream intermediary resource servers, to: 1. Request a delegation token from the authorization server with appropriate permissions (see Section 7). 2. Create delegated access tokens with the correct permissions, audience, and downstream resource identifiers (see Section 8). 6. Delegation Tokens and Delegated Access Tokens This section defines the properties of delegation tokens and delegated access tokens. The delegated authorization framework uses a hierarchical token structure where tokens form a chain: a delegation token can be used to create subordinate tokens, which can either be another delegation token (to continue the chain) or a delegated access token (to access protected resources). The top- level token in the chain is issued by the authorization server, while subordinate tokens are created by clients. 6.1. Delegation Tokens A delegation token is a token that can be used to create subordinate tokens. It contains a max_delegation_depth claim that limits the maximum length of the delegation chain. *delegation_key*: The cryptographic key bound to the delegation token, used by the client to sign subordinate tokens (either another delegation token or a delegated access token). The value is a JSON object representing the public key, using key format as defined in [RFC7517]. This claim MUST be present in delegation tokens. The corresponding private key is held by the client and used to create subordinate tokens. Subordinate tokens MUST include the parent delegation token in the delegation_token claim, creating a verifiable chain from the top-level token to the subordinate token. *max_delegation_depth*: OPTIONAL. Integer value indicating the maximum depth of the delegation chain. If not present, the delegation chain is unrestricted. When a client creates a subordinate token from a delegation token: Li, et al. Expires 7 January 2027 [Page 12] Internet-Draft Delegated-Auth July 2026 * If the parent delegation token has a max_delegation_depth value, the subordinate delegation token MUST have a max_delegation_depth value smaller than the parent's value. * If the parent delegation token does not have a max_delegation_depth value, the subordinate delegation token MAY set any max_delegation_depth value. When max_delegation_depth reaches 1, the subordinate token MUST be a delegated access token (no further delegation is allowed). The scope / authorization_details, aud, exp, and nbf claims MAY be present in delegation tokens and can be reduced in subordinate tokens. *scope* / *authorization_details*: The scope (as defined in [RFC8693]) or authorization details (as defined in [RFC9396]) of the delegation token. When creating a subordinate token, the client MAY reduce the scope or authorization_details to a subset of the parent token's permissions. *aud*: The audience of the delegation token. When creating a subordinate token, the client MAY narrow the audience to a subset of the parent token's audience. *exp*: The expiration time of the delegation token. When creating a subordinate token, the client MUST set an expiration time that is no later than the parent token's expiration time. *nbf*: The not-before time of the delegation token. When creating a subordinate token, the client MAY set a not-before time that is later than the parent token's not-before time. 6.1.1. Top Level Delegation Token The top-level delegation token is issued by the authorization server and MAY contain the iss, sub, and jti claims. If present, these claims apply to the entire token chain. These claims MUST NOT be present in subordinate delegation tokens or delegated access tokens. *iss*: The issuer of the delegation token. This claim applies to all subordinate tokens in the chain. *sub*: The subject of the delegation token, typically representing the resource owner or the client. This claim applies to all subordinate tokens in the chain. *jti*: Unique identifier for the delegation token. This claim Li, et al. Expires 7 January 2027 [Page 13] Internet-Draft Delegated-Auth July 2026 applies to all subordinate tokens in the chain. Subordinate delegation tokens and delegated access tokens MUST NOT include the iss, sub, or jti claims. Verifiers (resource servers) SHALL consider these claims from the top-level delegation token when validating the entire token chain. 6.2. Delegated Access Tokens A delegated access token is a token used to access protected resources. It cannot be used to create subordinate tokens. The scope, aud, exp, and nbf claims in delegated access tokens follow the same rules as in delegation tokens, as described in Section 6.1. *max_delegation_depth*: Delegated access tokens do not need to include a max_delegation_depth claim, even if the parent delegation token has one. If a delegated access token includes max_delegation_depth, its value MUST be 0. 7. Acquiring Delegation Tokens The client requests a delegation token using standard OAuth 2.0 grant types with additional parameters to distinguish delegation requests from standard token requests. 7.1. Authorization Code Grant For authorization code grant type, the client MUST include a delegation=true parameter in the authorization request to indicate that the client is requesting a delegation token instead of an OAuth 2.0 access token. Additionally, the authorization request MUST include either a scope parameter (as defined in [RFC6749] Section 3.3), an authorization_details parameter (as defined in "Rich Authorization Requests" [RFC9396]), or both, that define the permissions granted to the requested delegation token. In the token request, the client MUST include a delegation_key parameter with the value of the delegation key. The delegation key is a public key for digital signature. Additionally, the client MAY include in the token request either a scope parameter, an authorization_details parameter, or both. The client MAY also include a delegation=true parameter in the token request. Li, et al. Expires 7 January 2027 [Page 14] Internet-Draft Delegated-Auth July 2026 In the token response, the authorization server MUST include an access_token attribute whose value is the delegation token, and MUST include a token_type attribute valued "Delegation", and MAY include a refresh_token attribute which is the refresh token for obtaining a new delegation token via the refresh token grant. Other procedures of the authorization code grant are as described in [RFC6749]. Use of Proof Key for Code Exchange (PKCE) [RFC7636] is RECOMMENDED. 7.2. Other Grant Types Other OAuth 2.0 grant types, such as the refresh token grant or client credentials grant, MAY support delegated authorization by including the delegation and delegation_key parameters when applicable. The authorization server MUST validate that the client is authorized to request delegation tokens using the given grant type. 8. Creating Delegated Access Tokens The client creates delegated access tokens by: 1. Validating the delegation token's validity and permissions. 2. Generating a subordinate access token with (optionally) reduced privileges. 3. Applying cryptographic protection using the delegation key (digital signature). The client MUST include the delegation token in the delegation_token attribute of the delegated access token. The client MUST ensure that the delegated access token's scope, lifetime, audience, and other claims do not exceed those of the delegation token. The client MAY generate single-use delegated access tokens that the resource server or authorization server only consider valid when validating it for the first time. The client is RECOMMENDED to "sender-constrain" the delegated access tokens by binding the delegated access tokens with public keys or certificates where the corresponding private keys are held by the resource servers that will present those tokens, via techniques similar to OAuth 2.0 mTLS [RFC8705] or OAuth 2.0 DPoP [RFC9449]. Li, et al. Expires 7 January 2027 [Page 15] Internet-Draft Delegated-Auth July 2026 9. Using Delegated Access Tokens When the client accesses an intermediary resource server endpoint that requires downstream access, the client MUST include the delegated access token as a bearer token [RFC6750] in the Delegated- Authorization header. The delegated access token is used by downstream resource servers to verify requests from upstream intermediary resource servers. The Delegated-Authorization header MAY be used in combination with an Authorization header used by the intermediary resource server to verify the request from the client. For example: GET /dp-resource HTTP/1.1 Host: analytics.example.com Authorization: Bearer mF_9.B5g1234 Delegated-Authorization: Bearer mF_9.B5f-4.1JqM Upon receiving a request with a Delegated-Authorization header, the intermediary resource server can send downstream requests to one or more resource servers for the respective protected resources. For each such downstream request, the invoked resource server is the target resource server for that hop and can itself act as an intermediary resource server for subsequent downstream requests. The intermediary resource server MUST include the received delegated access token as a bearer token in the Authorization header. For example: GET /target-resource HTTP/1.1 Host: resource.example.com Authorization: Bearer mF_9.B5f-4.1JqM 10. Verification of Delegated Access Tokens Resource servers verify delegated access tokens through either local validation using pre-configured public keys or remote validation via token introspection [RFC7662] at the authorization server. 10.1. Local Verification The resource server verifies delegated access tokens by: 1. The resource server is pre-configured with the authorization server's public key, or it fetches the public key via the authorization server's JWKS endpoint [RFC7517]. Li, et al. Expires 7 January 2027 [Page 16] Internet-Draft Delegated-Auth July 2026 2. Checking the digital signature of the delegation token (part of the delegated access token) against the authorization server's public key. 3. Checking the digital signature of the delegated access token against the delegation key bound to the delegation token. 4. Verifying the delegated access token's permissions and validity are within the scope of the delegation token. 5. Verifying the delegated access token is within validity period, and the delegated access token's permissions cover the resource request. 10.2. Token Introspection The resource server sends the delegated access token to the authorization server via the token introspection endpoint [RFC7662]. The authorization server verifies the delegated access token against its keys. 11. Privacy Considerations This section describes the privacy properties of the local delegation approach defined in this specification. 11.1. Privacy Benefits When a client creates delegated access tokens locally using a delegation token, the authorization server only observes the initial delegation token request. After that, the client can independently issue subordinate tokens without further authorization server interaction. This provides the following privacy benefits: * *Minimized Authorization Server Visibility*: The authorization server does not learn which intermediary resource servers are authorized to access downstream resource servers, what resources they access, or when they access them. * *No Access Pattern Correlation*: The authorization server cannot track usage patterns or correlate activities across different resource servers. * *Reduced Data Collection*: The authorization server stores only metadata about the initial delegation token, not about each delegated access token. Li, et al. Expires 7 January 2027 [Page 17] Internet-Draft Delegated-Auth July 2026 * *Network Traffic Reduction*: Fewer network round-trips to the authorization server reduce exposure to network surveillance. 11.2. Relationship to Token Exchange Token Exchange [RFC8693] provides a mechanism for delegating access by having the client exchange one token for another at the authorization server. That approach requires authorization server involvement for each delegation event, which necessarily exposes delegation metadata to the authorization server. The local delegation approach in this specification performs delegation entirely on the client side after the initial token issuance, providing an alternative with different privacy characteristics. 11.3. Trade-offs While local delegation provides significant privacy benefits, implementations should consider: * *Client Responsibility*: The client must securely protect the delegation key and properly enforce delegation rules. * *Auditability*: Deployments requiring delegation event audits can implement client-side logging rather than relying on authorization server monitoring. * *Revocation*: If a delegation key is compromised, the authorization server may need to revoke the entire delegation token. 12. Security Considerations This specification extends OAuth 2.0 to support delegated authorization through hierarchical token issuance. While this enables fine-grained privilege delegation, it also introduces new trust and security considerations. * Delegation tokens MUST NOT be sent to resource servers without subordinate delegated access tokens. Resource servers and authorization servers MUST NOT treat delegation tokens as regular OAuth access tokens. * Clients MUST protect the delegation key, as compromise allows an attacker to mint valid delegated access tokens within the scope of the delegation token. Li, et al. Expires 7 January 2027 [Page 18] Internet-Draft Delegated-Auth July 2026 * Delegated access tokens SHOULD have short lifetimes and be bound to specific audiences, methods, and sender keys (e.g., via DPoP or mTLS) to mitigate replay and token leakage risks. Resource servers MUST validate both the delegation token and the delegated access token, ensuring the latter does not exceed the former’s permissions. * Token introspection CAN be used in scenarios where the tokens are kept opaque from the resource servers. If employed, token introspection responses MUST NOT reveal sensitive internal information. Authorization servers SHOULD enforce rate limiting and audit token issuance and validation activities. * Protected resource metadata published by resource servers is self- declared. Clients and authorization servers SHOULD verify that delegated access tokens remain within the intended scope of delegation. Clients SHOULD not trust delegated_resources or authorization_requirements metadata from untrusted resource servers without independent verification of the resource server's identity and authorization requirements. 13. Operational Considerations Deployments of this specification should consider the following operational aspects: * *Key Management*: Clients MUST securely store and rotate delegation keys. Authorization servers SHOULD support key rotation for delegation tokens and provide mechanisms to revoke compromised keys. * *Token Lifetimes*: Delegation tokens SHOULD have longer lifetimes than delegated access tokens to reduce authorization server load, and SHOULD be refreshable using refresh tokens. * *Metadata Caching*: Protected resource metadata published by resource servers at /.well-known/oauth-protected-resource can be cached by clients; a reasonable default TTL (e.g., 24 hours) is RECOMMENDED. * *Error Handling*: Resource servers SHOULD provide clear error responses (e.g., invalid token, insufficient scope) without exposing implementation details. * *Interoperability*: Implementers SHOULD ensure compatibility with existing OAuth 2.0 features such as PKCE, Rich Authorization Requests, and sender-constrained tokens. Li, et al. Expires 7 January 2027 [Page 19] Internet-Draft Delegated-Auth July 2026 14. IANA Considerations 14.1. OAuth Parameters Registry This specification registers the following parameters in the "OAuth Parameters" registry: *Delegation:* * *Name*: delegation * *Parameter Usage Location*: authorization request, token request * *Change Controller*: IETF * *Reference*: [this document] *Delegation Key:* * *Name*: delegation_key * *Parameter Usage Location*: token request * *Change Controller*: IETF * *Reference*: [this document] 14.2. OAuth Access Token Types Registry This specification registers the following parameters in the "OAuth Access Token Types" registry: * *Name*: Delegation * *Additional Token Endpoint Response Parameters*: (none) * *HTTP Authentication Scheme(s)*: Bearer * *Change Controller*: IETF * *Reference*: [this document] 14.3. HTTP Field Name Registry This specification registers the following parameters in the "Hypertext Transfer Protocol (HTTP) Field Name" registry: * *Field Name*: Delegated-Authorization Li, et al. Expires 7 January 2027 [Page 20] Internet-Draft Delegated-Auth July 2026 * *Status*: permanent * *Structured Type*: (none) * *Reference*: [this document] 14.4. OAuth Protected Resource Metadata Registry This specification registers the following entry in the "OAuth Protected Resource Metadata" registry defined in [RFC9728]: * *Metadata Name*: delegated_resources * *Metadata Description*: JSON object mapping downstream protected resource identifiers to the authorization capabilities for each. Each downstream resource value contains authorization_target and either scopes_supported or authorization_details_types_supported, indicating permissions that may be needed at that authorization target. * *Change Controller*: IETF * *Specification Document(s)*: [this document] * *Metadata Name*: authorization_requirements * *Metadata Description*: JSON array describing authorization requirements for specific endpoints or operations of the protected resource. Each entry can identify local requirements using scopes, authorization_details_types, or authorization_details, and can identify downstream delegated requirements using delegated_resources. Within delegated_resources, authorization_target distinguishes the protected resource to which the listed permissions apply. * *Change Controller*: IETF * *Specification Document(s)*: [this document] 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Li, et al. Expires 7 January 2027 [Page 21] Internet-Draft Delegated-Auth July 2026 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . Li, et al. Expires 7 January 2027 [Page 22] Internet-Draft Delegated-Auth July 2026 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . [I-D.lombardo-oauth-step-up-authz-challenge-proto] Lombardo, J., Babeanu, A., Zehavi, Y., and G. Fletcher, "OAuth 2.0 step-up authorization challenge proto", Work in Li, et al. Expires 7 January 2027 [Page 23] Internet-Draft Delegated-Auth July 2026 Progress, Internet-Draft, draft-lombardo-oauth-step-up- authz-challenge-proto-02, 30 June 2025, . 15.2. Informative References [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . Appendix A. Token Format The example tokens in this section are shown in Flattened JSON Serialization [RFC7515] [RFC7516], un-base64url-encoded and with comments for ease of reading. When used as JWTs [RFC7519], they should be represented in Compact Serialization [RFC7515] [RFC7516]. Similarly, they can be represented as CWTs [RFC8392]. A.1. Example 1 In this example, the delegation token is a JWS token signed with HS256, and the delegated access token is a JWS token signed with RS256. *Delegation Token*: Li, et al. Expires 7 January 2027 [Page 24] Internet-Draft Delegated-Auth July 2026 { "protected": { "_comment": "to be base64url-encoded", "alg": "HS256", "typ": "JWT", "kid": "as-key-1" }, "payload": { "_comment": "to be base64url-encoded", "iss": "https://as1.example.com", "sub": "user@example.com", "aud": "https://res1.example.com", "iat": 1772177588, "exp": 1774769588, "scope": "email:read email:send", "delegation_key": { "kty": "RSA", "n": "0Z5t3Rwhfz4MJxdNzg2I6Bsf9H_3kcMKtH6iwJsLV2DKO1MVcHb6wsxHZpqRePjm5Q1-pImr4pT67hCHyAR6kS4QbTrBZcjSe8lsvZIiifiBVWZxz8ZAfdj6EFSOWhFLZ0GVqe9NMslwX1hHOwmhRmMjGjexISPsZk5qN3gwqmD36H1GS-rE-cWlXI9f4pVcCdYqE0rfhZ7hDn5mrpWWY8wJuQa2jFqX-Fhyvt_Zh-qaa5Wp8cLJPS_ceAcLeS5mOYE58beelp51PuCDpq7a9fN4K_EpcSD7Ay0GrJxgN_VcLA7DgOAuU6zYDzk2KnmQ3qz35Tj5hy8jDHgF1AaSTw", "e": "AQAB" } }, "signature": "SBwdWhy4dissabBRoyyxMxRuVUbsFYv_1HZFeROLh5A" } *Delegated Access Token*: { "protected": { "_comment": "to be base64url-encoded", "alg": "RS256", "typ": "JWT", "kid": "delegation-key-1" }, "payload": { "_comment": "to be base64url-encoded", "sub": "https://dp1.example.com", "aud": "https://res1.example.com", "iat": 1772181188, "exp": 1772184788, "scope": "email:read", "delegationToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImFzLWtleS0xIn0.eyJpc3MiOiJodHRwczovL2FzMS5leGFtcGxlLmNvbSIsInN1YiI6InVzZXJAZXhhbXBsZS5jb20iLCJhdWQiOiJodHRwczovL3JlczEuZXhhbXBsZS5jb20iLCJpYXQiOjE3NzIxNzc1ODgsImV4cCI6MTc3NDc2OTU4OCwic2NvcGUiOiJlbWFpbDpyZWFkIGVtYWlsOnNlbmQiLCJkZWxlZ2F0aW9uX2tleSI6eyJrdHkiOiJSU0EiLCJuIjoiMFo1dDNSd2hmejRNSnhkTnpnMkk2QnNmOUhfM2tjTUt0SDZpd0pzTFYyREtPMU1WY0hiNndzeEhacHFSZVBqbTVRMS1wSW1yNHBUNjdoQ0h5QVI2a1M0UWJUckJaY2pTZThsc3ZaSWlpZmlCVldaeHo4WkFmZGo2RUZTT1doRkxaMEdWcWU5Tk1zbHdYMWhIT3dtaFJtTWpHamV4SVNQc1prNXFOM2d3cW1EMzZIMUdTLXJFLWNXbFhJOWY0cFZjQ2RZcUUwcmZoWjdoRG41bXJwV1dZOHdKdVFhMmpGcVgtRmh5dnRfWmgtcWFhNVdwOGNMSlBTX2NlQWNMZVM1bU9ZRTU4YmVlbHA1MVB1Q0RwcTdhOWZONEtfRXBjU0Q3QXkwR3JKeGdOX1ZjTEE3RGdPQXVVNnpZRHprMktubVEzcXozNVRqNWh5OGpESGdGMUFhU1R3IiwiZSI6IkFRQUIifX0.SBwdWhy4dissabBRoyyxMxRuVUbsFYv_1HZFeROLh5A" }, "signature": "df5sTdp6j-ULv3To3yqYFFZWLrY41wu6jpKfsZdjMNMeRH3TXY5nSc-lhdFfJElVGnyCa5Rf9YGlvacGVy84maFCq0zhNTiLL8xBYieCKTAhmMuWZvIUZFBoE1KBj2YXskpnU6CFTKhALbW5lidZSGXdcEnygxwaumpO_AxlYghU8RQrQgF1wAsoDLcoun1-FROuHUzqKGWqYSbXe1lGJ3dTt5ftod7SjGqM2Quz4BvfQMpw82VVGq7YlvRJMuPe4ITUeikFNQ672bvVrjhwHUlglQ9HuFj5iroHqwr6dLtfKVDBtw33A_lCnsWfk4vPWDJ-1fy3Klj4hT_bhBIVJA" } Li, et al. Expires 7 January 2027 [Page 25] Internet-Draft Delegated-Auth July 2026 A.2. Example 2 In this example, the delegation token chain consists of three tokens: a top-level delegation token issued by the authorization server, a subordinate delegation token created by the client, and a delegated access token created from the subordinate token. The top-level delegation token has max_delegation_depth of 3, which allows for two levels of delegation. *Top-Level Delegation Token*: { "protected": { "_comment": "to be base64url-encoded", "alg": "RS256", "typ": "JWT", "kid": "as-key-2" }, "payload": { "_comment": "to be base64url-encoded", "iss": "https://as1.example.com", "sub": "user@example.com", "aud": "https://res1.example.com", "iat": 1772177588, "exp": 1774769588, "scope": "email:read email:write email:send", "delegation_key": { "kty": "RSA", "n": "3O1EVa-_zsENOhylq99puKjF6NBq8S8Ntw9sufyCB9LrTSs-xRoDQ7X6rYbPEOn5E-6ASZyUW2vFxLacj0Wir05hznlnfRLRTmJhud4im5COfAhuiPeL0Mbs3WFLdBfWVGXSP2O5UNkd7dJ2KqudqxNF81Nrt51RpmPR59pUZS3REfAYgtqhQ07WuCTzd2VpFttPFurDSiWcriyELNdgsT9wap0nyceSVLQgY9ZgR0VvsmHj_LUKie1t5RCjTsaMHJH6x3QI0tjKG9Psbil0ORlhA9WEgOO6E6KOC_StEBnK_Ntb2ArGPDjlNPzTqWOeeev84MM8VXdRzpTLOrRmHQ", "e": "AQAB" }, "max_delegation_depth": 3 }, "signature": "p1OjJQ2tASuFPPCXzdbuSHaZiPTF2jM1Z_My2_qPx0IAAJJ5RVo9Km2hFeXjqqGcjkG5wEFxMw_q8JO48O9bVaKNBa1k_-UoBxf5KlMpldMFIUyV4D8Sugshh73iqVii5HW2MY4uS5Gj46GDUcX1NQRg8LW6Wa4zso0SPfIfunXF0dvBG24cCUoIFOr1NzryZ7OcVt9kdC4_uXGoSmjtGl1XsRvgb216fZFuZV0F88zWFsDcBZn4i8qGcBS2XAHjW4jbH7Y1O8dvl2h0afftmNkG2ZgHPl3phj_i-unQsAxhCUI_8MjtfF5iwe586uQw_1iED2IUlEXOgX-Ld5GgTw" } *Subordinate Delegation Token*: Li, et al. Expires 7 January 2027 [Page 26] Internet-Draft Delegated-Auth July 2026 { "protected": { "_comment": "to be base64url-encoded", "alg": "RS256", "typ": "JWT", "kid": "delegation-key-2" }, "payload": { "_comment": "to be base64url-encoded", "aud": "https://res1.example.com", "iat": 1772181188, "exp": 1772782388, "max_delegation_depth": 1, "scope": "email:read email:write", "delegationToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImFzLWtleS0yIn0.eyJpc3MiOiJodHRwczovL2FzMS5leGFtcGxlLmNvbSIsInN1YiI6InVzZXJAZXhhbXBsZS5jb20iLCJhdWQiOiJodHRwczovL3JlczEuZXhhbXBsZS5jb20iLCJpYXQiOjE3NzIxNzc1ODgsImV4cCI6MTc3NDc2OTU4OCwic2NvcGUiOiJlbWFpbDpyZWFkIGVtYWlsOndyaXRlIGVtYWlsOnNlbmQiLCJkZWxlZ2F0aW9uX2tleSI6eyJrdHkiOiJSU0EiLCJuIjoiM08xRVZhLV96c0VOT2h5bHE5OXB1S2pGNk5CcThTOE50dzlzdWZ5Q0I5THJUU3MteFJvRFE3WDZyWWJQRU9uNUUtNkFTWnlVVzJ2RnhMYWNqMFdpcjA1aHpubG5mUkxSVG1KaHVkNGltNUNPZkFodWlQZUwwTWJzM1dGTGRCZldWR1hTUDJPNVVOa2Q3ZEoyS3F1ZHF4TkY4MU5ydDUxUnBtUFI1OXBVWlMzUkVmQVlndHFoUTA3V3VDVHpkMlZwRnR0UEZ1ckRTaVdjcml5RUxOZGdzVDl3YXAwbnljZVNWTFFnWTlaZ1IwVnZzbUhqX0xVS2llMXQ1UkNqVHNhTUhKSDZ4M1FJMHRqS0c5UHNiaWwwT1JsaEE5V0VnT082RTZLT0NfU3RFQm5LX050YjJBckdQRGpsTlB6VHFXT2VlZXY4NE1NOFZYZFJ6cFRMT3JSbUhRIiwiZSI6IkFRQUIifSwibWF4X2RlbGVnYXRpb25fZGVwdGgiOjN9.p1OjJQ2tASuFPPCXzdbuSHaZiPTF2jM1Z_My2_qPx0IAAJJ5RVo9Km2hFeXjqqGcjkG5wEFxMw_q8JO48O9bVaKNBa1k_-UoBxf5KlMpldMFIUyV4D8Sugshh73iqVii5HW2MY4uS5Gj46GDUcX1NQRg8LW6Wa4zso0SPfIfunXF0dvBG24cCUoIFOr1NzryZ7OcVt9kdC4_uXGoSmjtGl1XsRvgb216fZFuZV0F88zWFsDcBZn4i8qGcBS2XAHjW4jbH7Y1O8dvl2h0afftmNkG2ZgHPl3phj_i-unQsAxhCUI_8MjtfF5iwe586uQw_1iED2IUlEXOgX-Ld5GgTw" }, "signature": "lnf8Wz5M_B4dVTOOjT0aQa0ZSqEbTZVGb1HU_dk1tJ4eCbkCB8lmO0wJXc07Ys8gKqqb3TS4tKUbnwwKo3_Dw3FGYjbDqDE7rBtdc0lqi6fKSecff2ujVCi2U2dLjX78_h7U0LP1XbJuhkjdBYa-_mwiygAXf0j8cilXTigbTWJfgqcziVmkJzl9a_5HJ8HYF5ohdGmVBhOfyRrwGikYoHEQB6Ye_6jwTD_IQsUJe0eYdD4xAdA7C2awZAvhdYduKXit7WSyGuEhbyKopsm6WVZz4BkjWDjcJ2S7Xjb6RxPCGc_nNiAMsGT1nG9MIj-oGYy8gIWPSLEyF_6sk8hiaQ" } *Delegated Access Token*: { "protected": { "_comment": "to be base64url-encoded", "alg": "RS256", "typ": "JWT", "kid": "delegation-key-2-sub" }, "payload": { "_comment": "to be base64url-encoded", "sub": "https://dp1.example.com", "aud": "https://res1.example.com", "iat": 1772184788, "exp": 1772188388, "scope": "email:read", "delegationToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRlbGVnYXRpb24ta2V5LTIifQ.eyJhdWQiOiJodHRwczovL3JlczEuZXhhbXBsZS5jb20iLCJpYXQiOjE3NzIxODExODgsImV4cCI6MTc3Mjc4MjM4OCwibWF4X2RlbGVnYXRpb25fZGVwdGgiOjEsInNjb3BlIjoiZW1haWw6cmVhZCBlbWFpbDp3cml0ZSIsImRlbGVnYXRpb25Ub2tlbiI6ImV5SmhiR2NpT2lKU1V6STFOaUlzSW5SNWNDSTZJa3BYVkNJc0ltdHBaQ0k2SW1GekxXdGxlUzB5SW4wLmV5SnBjM01pT2lKb2RIUndjem92TDJGek1TNWxlR0Z0Y0d4bExtTnZiU0lzSW5OMVlpSTZJblZ6WlhKQVpYaGhiWEJzWlM1amIyMGlMQ0poZFdRaU9pSm9kSFJ3Y3pvdkwzSmxjekV1WlhoaGJYQnNaUzVqYjIwaUxDSnBZWFFpT2pFM056SXhOemMxT0Rnc0ltVjRjQ0k2TVRjM05EYzJPVFU0T0N3aWMyTnZjR1VpT2lKbGJXRnBiRHB5WldGa0lHVnRZV2xzT25keWFYUmxJR1Z0WVdsc09uTmxibVFpTENKa1pXeGxaMkYwYVc5dVgydGxlU0k2ZXlKcmRIa2lPaUpTVTBFaUxDSnVJam9pTTA4eFJWWmhMVjk2YzBWT1QyaDViSEU1T1hCMVMycEdOazVDY1RoVE9FNTBkemx6ZFdaNVEwSTVUSEpVVTNNdGVGSnZSRkUzV0RaeVdXSlFSVTl1TlVVdE5rRlRXbmxWVnpKMlJuaE1ZV05xTUZkcGNqQTFhSHB1Ykc1bVVreFNWRzFLYUhWa05HbHROVU5QWmtGb2RXbFFaVXd3VFdKek0xZEdUR1JDWmxkV1IxaFRVREpQTlZWT2EyUTNaRW95UzNGMVpIRjRUa1k0TVU1eWREVXhVbkJ0VUZJMU9YQlZXbE16VWtWbVFWbG5kSEZvVVRBM1YzVkRWSHBrTWxad1JuUjBVRVoxY2tSVGFWZGpjbWw1UlV4T1pHZHpWRGwzWVhBd2JubGpaVk5XVEZGbldUbGFaMUl3Vm5aemJVaHFYMHhWUzJsbE1YUTFVa05xVkhOaFRVaEtTRFo0TTFGSk1IUnFTMGM1VUhOaWFXd3dUMUpzYUVFNVYwVm5UMDgyUlRaTFQwTmZVM1JGUW01TFgwNTBZakpCY2tkUVJHcHNUbEI2VkhGWFQyVmxaWFk0TkUxTk9GWllaRko2Y0ZSTVQzSlNiVWhSSWl3aVpTSTZJa0ZSUVVJaWZTd2liV0Y0WDJSbGJHVm5ZWFJwYjI1ZlpHVndkR2dpT2pOOS5wMU9qSlEydEFTdUZQUENYemRidVNIYVppUFRGMmpNMVpfTXkyX3FQeDBJQUFKSjVSVm85S20yaEZlWGpxcUdjamtHNXdFRnhNd19xOEpPNDhPOWJWYUtOQmExa18tVW9CeGY1S2xNcGxkTUZJVXlWNEQ4U3Vnc2hoNzNpcVZpaTVIVzJNWTR1UzVHajQ2R0RVY1gxTlFSZzhMVzZXYTR6c28wU1BmSWZ1blhGMGR2QkcyNGNDVW9JRk9yMU56cnlaN09jVnQ5a2RDNF91WEdvU21qdEdsMVhzUnZnYjIxNmZaRnVaVjBGODh6V0ZzRGNCWm40aThxR2NCUzJYQUhqVzRqYkg3WTFPOGR2bDJoMGFmZnRtTmtHMlpnSFBsM3Boal9pLXVuUXNBeGhDVUlfOE1qdGZGNWl3ZTU4NnVRd18xaUVEMklVbEVYT2dYLUxkNUdnVHcifQ.lnf8Wz5M_B4dVTOOjT0aQa0ZSqEbTZVGb1HU_dk1tJ4eCbkCB8lmO0wJXc07Ys8gKqqb3TS4tKUbnwwKo3_Dw3FGYjbDqDE7rBtdc0lqi6fKSecff2ujVCi2U2dLjX78_h7U0LP1XbJuhkjdBYa-_mwiygAXf0j8cilXTigbTWJfgqcziVmkJzl9a_5HJ8HYF5ohdGmVBhOfyRrwGikYoHEQB6Ye_6jwTD_IQsUJe0eYdD4xAdA7C2awZAvhdYduKXit7WSyGuEhbyKopsm6WVZz4BkjWDjcJ2S7Xjb6RxPCGc_nNiAMsGT1nG9MIj-oGYy8gIWPSLEyF_6sk8hiaQ" }, "signature": "mn-0y0F3lx0IM-60UsBp1_M7uRhdT28dPqxt6-s1OnjM-obyF-p5XbQV9jI5Q56X4cb3jLl6RkM789ODTGt5y4QNdOA2WhlS0WldSOzYkV1Xj2yrC0mZakYCHTpzzgvfeUjeNj-fDWmtgRb2Lfm6Z6dguT071WQkaIyH4IW5xVxroqbn1tFM07uX3huIV9tC_iS926rWaDW7eQDm1nhhjS_QSgUcTF1eJy7hOjEtzs70iij5bQU-B9nn6OfXdpb1jO5vx3lCSnZfL2h2EaQYK3CbjrflbDnIYKtJ0NMx5D03KRcv_uPlG5HHRL5cuMz8eToKc08rc0Qs5PxDbeqV4A" } Appendix B. Integration with Step-Up Authorization This specification can be used together with step-up authorization [I-D.lombardo-oauth-step-up-authz-challenge-proto]. When a resource server returns an insufficient_authorization error, the client can create a new delegated access token with the required permissions from its existing delegation token. Li, et al. Expires 7 January 2027 [Page 27] Internet-Draft Delegated-Auth July 2026 This is particularly useful for AI agents that hold a delegation token. Upon receiving a step-up authorization challenge, the agent can automatically create a new delegated access token with the additional authorization_details required by the resource server, without requiring the user to re-authenticate. Resource servers that support both delegated authorization and step- up challenges SHOULD use the body_instructions parameter to specify the exact authorization_details or scope required. Appendix C. Use Cases C.1. Delegating Subset of Access Rights to Specialized AI Agents Enterprise Identity and Access Management systems often employ Role Based Access Control (RBAC) or Attribute Based Access Control (ABAC), assigning a set of minimal permissions to the employee based on their role, department, or other attributes. AI Agent can be an employee's personal assistant, or a virtual employee of a certain department in general. The permissions delegated to an AI agent CAN be long-term, but an AI agent MUST NOT directly inherit all its owner's access rights. Rather, they SHOULD be a subset of its owner, bound to specific service/API/database/codebase according to its specialty and dedicated workflow. +=======================+===========================================+ | Role | Service / Component | +=======================+===========================================+ | Resource Owner | an enterprise, individual or | | | a department | +-----------------------+-------------------------------------------+ | Client | agent's client application | +-----------------------+-------------------------------------------+ | Intermediary Resource | CI-CD agent, test agent, DEV | | Server | agent, research agent | +-----------------------+-------------------------------------------+ | Authorization Server | enterprise IAM system | +-----------------------+-------------------------------------------+ | Downstream / Target | enterprise IT systems | | Resource Server(s) | | +-----------------------+-------------------------------------------+ | Downstream / Target | DEV/STAGE/PROD environments, | | Protected Resource(s) | internal knowledge database | +-----------------------+-------------------------------------------+ Table 1: AI Agents Li, et al. Expires 7 January 2027 [Page 28] Internet-Draft Delegated-Auth July 2026 C.2. Third-Party Analytics Platform Integrated in an Enterprise SaaS In this scenario, a corporate customer uses a Software-as-a-Service (SaaS) Customer Relationship Management (CRM) application. The customer wishes to gain business insights by granting a specialized third-party analytics platform limited access to its CRM data. The CRM application obtains a delegation token from the enterprise's identity provider. It then creates a narrowly scoped delegated access token for the analytics service. This token only permits read access to a predefined, non-sensitive subset of customer data (e.g., names and identifiers, but not personal email addresses). The analytics platform uses this token to pull data, generates an aggregated business intelligence report, and delivers it back to the CRM application for the corporate customer to view. +========================================+========================+ | Role | Service / Component | +========================================+========================+ | Resource Owner | company A (the tenant) | +----------------------------------------+------------------------+ | Client | SaaS CRM application | +----------------------------------------+------------------------+ | Intermediary Resource Server | analytics service | +----------------------------------------+------------------------+ | Authorization Server | enterprise IdP | +----------------------------------------+------------------------+ | Downstream / Target Resource Server(s) | CRM application server | +----------------------------------------+------------------------+ | Downstream / Target Protected | CRM application's data | | Resource(s) | retrieval API | +----------------------------------------+------------------------+ Table 2: Enterprise-SaaS Authors' Addresses Ruochen Li Huawei Int. Pte Ltd Email: li.ruochen@h-partners.com Haiguang Wang Huawei Int. Pte Ltd Email: wang.haiguang.shieldlab@huawei.com Li, et al. Expires 7 January 2027 [Page 29] Internet-Draft Delegated-Auth July 2026 Chunchi Peter Liu Huawei Technologies Email: liuchunchi@huawei.com Tieyan Li Huawei Int. Pte Ltd Email: Li.Tieyan@huawei.com Li, et al. Expires 7 January 2027 [Page 30]