]> Huawei Int. Pte Ltd

li.ruochen@h-partners.com

Huawei Int. Pte Ltd

wang.haiguang.shieldlab@huawei.com

Huawei Technologies

liuchunchi@huawei.com

Huawei Int. Pte Ltd

Li.Tieyan@huawei.com

oauth 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 a delegated party while maintaining fine-grained control over delegated permissions. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OAuth 2.0 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 two-token architecture that decouples initial authorization from final resource access.

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 when, and only when, they appear in all capitals, as shown here.

Terminology This specification uses the following terms defined in OAuth 2.0 : authorization server, client, resource server, and resource owner. The following additional terms are used throughout this document:

Delegated Party (DP):

An entity (e.g., a service, component, or application) authorized by the client to access protected resources on behalf of the resource owner.

Delegated Resource:

A resource or API endpoint hosted by the delegated party that requires access to the resource owner’s protected data at a target resource server.

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.

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.

| | | | 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 | | | +----------------------> | | Delegated | | Resource | | Party | 6. Protected | Server | | | Resource | | | <----------------------+ | +-----------+ +---------------+ ]]>

The client requests authorization from the resource owner. The client indicates in the authorization request that the requested authorization grant is for delegated authorization. The client receives an authorization grant. 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. The authorization server authenticates the client and validates the authorization grant, and if valid, issues a delegation token. The client calls the delegated party'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 delegated party requests the target protected resource from the resource server and presents the delegated access token. The resource server validates the delegated access token, and if valid, serves the resource. The delegated party receives the resource, optionally transforms it into a service-specific response (also known as delegated resource), and returns it to the client. Both delegation token and delegated access token can be JSON Web Tokens (JWTs) or CBOR Web Tokens (CWTs) .

Delegated Party Metadata Before the OAuth 2.0 client retrieves a delegation token and generates a delegated access token for the delegated party, the client needs to obtain the authorization server endpoint and the permissions needed by the delegated party. Such information can be manually configured into the client, or it can be dynamically discovered through delegated party metadata. Delegated party metadata enables OAuth 2.0 clients to obtain information needed to interact with a delegated party. The structure of the metadata format is similar to "OAuth 2.0 Authorization Server Metadata" and "OAuth 2.0 Protected Resource Metadata" . The delegated party metadata is retrieved from a well-known location as a JSON document. By default, the well-known URI string used is /.well-known/oauth-delegated-party.

Delegated Party Metadata Attributes

resources:

RECOMMENDED. JSON array containing a list of target protected resources' resource identifiers, as defined in . Either this attribute or authorization_servers defined below MUST be present.

authorization_servers:

OPTIONAL. JSON array containing a list of OAuth authorization server issuer identifiers, as defined in . Either this attribute or resources defined above MUST be present.

permissions_supported:

RECOMMENDED. JSON object indicating the permissions the delegated party may request. The scopes attribute lists supported scope values ; the authorization_details attribute lists supported rich authorization request objects as defined in . These guide the client in constructing valid authorization and token requests. Either the scopes attribute or the authorization_details attribute must be present.

api_permissions:

RECOMMENDED. JSON object mapping API endpoints (resource identifiers) to the permissions required to access them. Each value can include scopes and/or authorization_details to specify the permissions needed for that endpoint/resource.

delegated_party_documentation:

OPTIONAL: URL of a page containing human-readable information that developers might want or need to know when using the delegated party. The value of this field MAY be internationalized.

Delegated Party Metadata Example The following is a non-normative example delegated party metadata:

WWW-Authenticate Upon receipt of a request for a delegated resource that lacks credentials, the delegated party can reply with a challenge using the 401 (Unauthorized) status code ( Section 15.5.2) and the WWW-Authenticate header field ( Section 11.6.1). This specification introduces a new parameter in the WWW-Authenticate HTTP response header field to indicate the delegated party metadata URL:

delegated_party_metadata:

The URL of the delegated party metadata.

The response below is an example of a WWW-Authenticate header that includes the delegated party metadata URL. NOTE: '\' line wrapping per .

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.

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 . 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:

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 ) or authorization details (as defined in ) 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.

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 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 and delegated parties) SHALL consider these claims from the top-level delegation token when validating the entire token chain.

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.

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.

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 Section 3.3), an authorization_details parameter (as defined in "Rich Authorization Requests" ), 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. 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 . Use of Proof Key for Code Exchange (PKCE) is RECOMMENDED.

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.

Creating Delegated Access Tokens The client creates delegated access tokens by: Validating the delegation token's validity and permissions. Generating a subordinate access token with (optionally) reduced privileges. 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 owned by the delegated parties, via techniques similar to OAuth 2.0 mTLS or OAuth 2.0 DPoP .

Using Delegated Access Tokens When the client accesses a delegated resource on the delegated party, the client MUST include the delegated access token as a bearer token in the Delegated-Authorization header, used by the target resource server to verify requests from the delegated party. The Delegated-Authorization header MAY be used in combination with an Authorization header used by the delegated party to verify the request from the client. For example:

Upon receiving a delegated resource request with a Delegated-Authorization header, the delegated party sends a request to the target resource server for the respective target resource. The delegated party MUST include the received delegated access token as a bearer token in the Authorization header. For example:

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 at the authorization server.

Local Verification The resource server verifies delegated access tokens by: 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 . Checking the digital signature of the delegation token (part of the delegated access token) against the authorization server's public key. Checking the digital signature of the delegated access token against the delegation key bound to the delegation token. Verifying the delegated access token's permissions and validity are within the scope of the delegation token. Verifying the delegated access token is within validity period, and the delegated access token's permissions cover the resource request.

Token Introspection The resource server sends the delegated access token to the authorization server via the token introspection endpoint . The authorization server verifies the delegated access token against its keys.

Privacy Considerations This section describes the privacy properties of the local delegation approach defined in this specification.

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 delegated parties are authorized, 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 delegated parties. Reduced Data Collection: The authorization server stores only metadata about the initial delegation token, not about each delegated access token. Network Traffic Reduction: Fewer network round-trips to the authorization server reduce exposure to network surveillance.

Relationship to Token Exchange Token Exchange 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.

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.

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. 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 delegated party and the resource server. If employed, token introspection responses MUST NOT reveal sensitive internal information. Authorization servers SHOULD enforce rate limiting and audit token issuance and validation activities.

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: Delegated party metadata at the well-known URI /.well-known/oauth-delegated-party can be cached by clients; a reasonable default TTL (e.g., 24 hours) is RECOMMENDED. Error Handling: Delegated parties and 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.

IANA Considerations

Well-Known URIs Registry This specification registers the following entry in the "Well-Known URIs" registry: URI suffix: oauth-delegated-party Reference: [this document] Status: permanent Change controller: IETF Related information: (none)

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]

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]

HTTP Field Name Registry This specification registers the following parameters in the "Hypertext Transfer Protocol (HTTP) Field Name" registry: Field Name: Delegated-Authorization Status: permanent Structured Type: (none) Reference: [this document]

OAuth Delegated Party Metadata Registry This specification establishes the "OAuth Delegated Party Metadata" registry for OAuth 2.0 delegated party metadata names. The registry records the delegated party metadata parameter and a reference to the specification that defines it.

Registration Template

Metadata Name:

The name requested (e.g., "resource"). This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the designated experts state that there is a compelling reason to allow an exception.

Metadata Description:

Brief description of the metadata (e.g., "Resource identifier URL").

Change Controller:

For IETF Stream RFCs, list "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

Specification Document(s):

Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

Initial Registry Contents Resources: Metadata Name: resources Metadata Description: JSON array containing a list of target protected resources' resource identifier URLs Change Controller: IETF Specification Document(s): [this document] Authorization Servers: Metadata Name: authorization_servers Metadata Description: JSON array containing a list of authorization server issuer identifiers Change Controller: IETF Specification Document(s): [this document] Supported Permissions: Metadata Name: permissions_supported Metadata Description: JSON object indicating the permissions the delegated party may request Change Controller: IETF Specification Document(s): [this document] API Permissions: Metadata Name: api_permissions Metadata Description: JSON object mapping API endpoints (resource identifiers) to the permissions required to access them Change Controller: IETF Specification Document(s): [this document] Delegated Party Documentation: Metadata Name: delegated_party_documentation Metadata Description: URL of a page containing human-readable information that developers might want or need to know when using the delegated party Change Controller: IETF Specification Document(s): [this document]

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. AWS IndyKite Raiffeisen Bank International Practical Identity It is not uncommon for resource servers to require additional information like details of delegation authorization, or assurance proof of the delegation of authorization mechanism used according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the data and metadata associated with the access token of the current request does not meet its authorization requirements and, further, how to meet them. This document also codifies a taxonomy to guide the client into starting a new request towards the authorization server in order to get issued, if applicable, a new set of tokens matching the requirements. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.

Token Format The example tokens in this section are shown in Flattened JSON Serialization , un-base64url-encoded and with comments for ease of reading. When used as JWTs , they should be represented in Compact Serialization . Similarly, they can be represented as CWTs .

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:

Delegated Access Token:

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:

Subordinate Delegation Token:

Delegated Access Token:

Integration with Step-Up Authorization This specification can be used together with step-up authorization . 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. 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.

Use Cases

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 Delegated Party CI-CD agent, test agent, DEV agent, research agent Authorization Server enterprise IAM system Resource Server enterprise IT systems Target Protected Resource DEV/STAGE/PROD environments, internal knowledge database

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 Delegated Party analytics service Authorization Server enterprise IdP Resource Server CRM application server Target Protected Resource CRM application's data retrieval API