Delegation Chain for OAuth 2.0

Internet-Draft	OAuth Delegation Chain	July 2026
Liu, et al.	Expires 8 January 2027	[Page]

Abstract

RFC 8693 defines the act claim for multi-hop actor identification in JWTs but does not record per-hop policy constraints or provide delegator cryptographic confirmation. This specification defines the delegation_chain JWT claim as a structured companion to act: an ordered array of delegation records capturing the Authorization Server's attestation, the delegated policy constraints at each hop, and an optional delegator cryptographic confirmation. Together, act and delegation_chain provide both runtime authorization and verifiable delegation lineage. The specification also defines cross-domain delegation support and an optional user interaction mechanism for delegation consent.¶

1. Introduction

In multi-agent systems, a primary agent (Agent A) may need to delegate a subset of its authorized operations to a secondary agent (Agent B), which may in turn delegate further to Agent C. Each delegation hop must preserve the original user's authorization intent while constraining what each downstream agent is permitted to do.¶

OAuth 2.0 already provides building blocks for expressing delegation. RFC 8693 defines the act claim, which supports nested multi-hop actor identification (enabling a token to express that Agent A delegated to Agent B, which in turn delegated to Agent C). [I-D.ietf-oauth-identity-chaining] defines the cross-domain transport pattern combining Token Exchange ([RFC8693]) and JWT Authorization Grant ([RFC7523]) to carry identity and authorization information across trust domain boundaries. Together, these mechanisms address the runtime dimension of delegation: who is currently acting, and how to move tokens across domains.¶

However, three structural gaps remain for agent delegation scenarios:¶

Per-hop policy constraint: The act claim identifies the actors at each hop but does not record what authorization constraints were applied at each delegation step. A downstream Resource Server sees the final scope but cannot verify whether intermediate agents narrowed or expanded the authorization along the way.¶
Delegator cryptographic confirmation: The act claim is constructed unilaterally by the Authorization Server. The delegating agent leaves no independent cryptographic evidence that it authorized a specific delegation. This limits non-repudiation and post-hoc audit capabilities.¶
User interaction for delegation: Neither act nor identity chaining defines a mechanism for pausing a delegation flow to obtain explicit user consent. This is a gap specific to agent scenarios, where agents may autonomously delegate to other agents without the user's awareness.¶

This specification introduces the delegation_chain claim as a structured companion to act. While act provides runtime actor identification for authorization decisions, delegation_chain records the full delegation history as an ordered array of delegation records. Each record captures the AS's attestation and, when present, the delegated policy at that hop, and MAY additionally carry the delegator's cryptographic confirmation, ensuring that neither the AS nor any delegating agent can unilaterally construct or deny a delegation record. The two claims coexist in the same token: act answers "who is acting now" for the Resource Server, while delegation_chain answers "how was this authorization delegated, step by step" for verification and compliance systems.¶

The delegation_chain claim addresses the delegation lineage and verification dimension of complex delegation, complementing the runtime semantics provided by existing OAuth mechanisms. Cross-domain delegation (Section 8) addresses the multi-domain scenario. This version of the specification focuses on linear delegation chains; other complex topologies such as diamond-shaped delegation, where multiple paths converge on the same agent, may be addressed by future extensions.¶

Scope Boundary: This specification addresses problems that lie outside the design scope of Token Exchange ([RFC8693]) and Identity Chaining ([I-D.ietf-oauth-identity-chaining]). Token Exchange defines how to convert one token into another but does not record the delegation lineage across multiple hops. Identity Chaining defines how to transport identity across trust domains but intentionally leaves Claims Transcription representation undefined. The three problems solved by this specification (multi-hop delegation lineage, delegator non-repudiation, and delegation consent interaction) are orthogonal to both token conversion and cross-domain transport. Absorbing this mechanism into either existing specification would broaden their scope beyond their original design intent and impose delegation lineage complexity on deployments that do not need it.¶

Relationship to Compositional Approaches: [I-D.klrc-aiagent-auth] demonstrates how existing OAuth mechanisms — Token Exchange, Transaction Tokens, and CIBA — can be composed to address agent authentication and authorization. This specification complements that compositional approach by defining the delegation lineage layer that composition of existing mechanisms alone does not provide: per-hop delegator cryptographic confirmation and verifiable delegation history. The two approaches are designed to coexist — compositional frameworks provide the transport and runtime semantics, while delegation_chain provides the structured delegation record and non-repudiation layer.¶

Deployment Options: A minimal deployment requires only the delegation_chain claim structure (Section 4), the delegation Token Exchange flow (Section 6), and the AS validation rules (Section 5.2). Implementations MAY additionally support structured policy (delegated_policy), user interaction (Section 5), cross-domain delegation (Section 8), delegator_signature, and authorization evidence propagation, depending on deployment requirements.¶

1.1. 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.¶

2. Relationship to Existing Mechanisms

This section describes how the delegation_chain claim relates to existing OAuth 2.0 mechanisms, establishing the precise boundary between runtime delegation semantics and structured delegation records.¶

2.1. Relationship to the act Claim

RFC 8693 defines the act claim to express that delegation has occurred and to identify the acting party. The act claim supports nested multi-hop actor chains: a token can express that Agent A delegated to Agent B, which delegated to Agent C, all within a single nested JSON structure. This nesting enables Resource Servers to identify the current actor and trace the actor lineage for authorization decisions.¶

The act claim is constructed by the Authorization Server alone: the AS assembles the nested actor chain without requiring independent proof from each delegating agent. This is sufficient for runtime authorization decisions but does not capture per-hop policy constraints or delegator consent.¶

The delegation_chain claim complements act by recording the delegation lineage as a structured array of records. Each record captures, when present, the AS's per-hop attestation (as_signature), the policy constraints applied at that hop (scope, and, when present, delegated_policy), and the delegator's own cryptographic proof (delegator_signature). This enables:¶

Per-hop policy constraints: Each delegation record carries the policy that was applied at that hop, not just the final scope. This preserves the full delegation lineage and enables policy narrowing verification.¶
Delegator proof: The optional delegator_signature on each record provides independent evidence of each delegator's consent, enabling non-repudiation that the AS alone cannot provide.¶
User interaction: The delegation flow supports optional user consent interaction (Section 5) at each hop, which is outside the scope of act.¶

In a token carrying both claims, act identifies the current actor for the Resource Server's authorization decision, while delegation_chain provides the structured delegation record from the current actor back to the original human principal. The delegatee_id of the most recent delegation record (index 0) MUST match the act.sub value, ensuring continuity between the two claims. delegation_chain is thus a companion claim that preserves act's original RFC 8693 semantics (current actor identification) while adding multi-hop delegation history as a separate, independently verifiable structure.¶

2.2. Relationship to Identity Chaining

[I-D.ietf-oauth-identity-chaining] defines a general-purpose pattern for preserving identity and authorization information across trust domains, combining Token Exchange ([RFC8693]) and JWT Authorization Grant ([RFC7523]). It addresses the transport dimension of cross-domain delegation: how to move a token from Domain A to Domain B while preserving the user identity and authorization context.¶

This specification reuses the identity chaining transport for cross-domain delegation (Section 8) and adds agent-specific extensions:¶

delegation_chain claim: An explicit, cryptographically signed delegation record of all delegation hops, which identity chaining does not define;¶
Policy narrowing enforcement: Each delegation hop MUST carry a scope equal to or narrower than its predecessor; structured policy (delegated_policy) is additionally enforced when present;¶
Optional dual-signature security: Both the AS and the delegating agent can sign each delegation record, preventing unilateral forgery; deployments that omit delegator_signature rely on AS signature alone;¶
Agent Identifier URIs: Resolvable URI-based identity for delegators and delegatees, supporting WIT and SPIFFE schemes.¶

The key distinction in deployment context is scope: identity chaining addresses general cross-domain identity propagation (human users, CI/CD pipelines, SSO extension), while this specification profiles that transport specifically for agent-to-agent delegation with delegation lineage requirements.¶

2.3. Relationship to Claims Transcription

Section 2.5 of [I-D.ietf-oauth-identity-chaining] defines Claims Transcription (the process by which Authorization Servers add, change, or remove claims when producing JWT authorization grants or access tokens during cross-domain flows). That specification explicitly leaves the representation of transcribed claims undefined: "The representation of transcribed claims and their format is not defined in this specification."¶

The delegation_chain claim provides one such representation. When delegation crosses a trust domain boundary, each delegation record captures the transcribed policy (when present, delegated_policy) and the cryptographic evidence of the transcribing parties (the AS via as_signature and the delegator via delegator_signature, each when present). This enables the receiving domain to verify not just what was transcribed but who authorized the transcription and under what constraints, closing the representation gap left by identity chaining.¶

Implementations using identity chaining for cross-domain delegation SHOULD include the delegation_chain claim in the JWT authorization grant as a structured Claims Transcription format, enabling the receiving AS to validate the delegation lineage before issuing a local access token.¶

4. The delegation_chain Claim

4.1. Claim Definition

Claim Name:: delegation_chain¶
Claim Type:: Array of Objects¶
Usage:: Access tokens (JWT format)¶
Specification:: [RFC7519] (JWT)¶

4.2. Structure

The delegation_chain is an ordered array of delegation records, from most recent to earliest. Each record represents one delegation hop.¶

The following example shows a delegation record with WIT-based agent identifiers, a machine-enforceable structured policy, a root evidence reference, and dual signatures:¶

{
  "delegation_chain": [
    {
      "delegator_id": "wit://agent-a.example/sha256.aaa111...",
      "delegatee_id": "wit://agent-b.example/sha256.bbb222...",
      "as_id": "https://as.example.com",
      "delegation_timestamp": 1734516900,
      "root_evidence_ref": "evidence-root-abc123",
      "delegated_policy": {
        "type": "rego",
        "content": "package agent\ndefault allow = false\n\nallow if {\n  input.action == \"inventory_check\"\n  input.item_id == \"123\"\n}",
        "entry_point": "allow"
      },
      "operation_summary": "Delegate inventory check for item 123",
      "delegator_signature": "eyJhbGciOiJFUzI1NiJ9..MEYCIQD...",
      "as_signature": "eyJhbGciOiJSUzI1NiJ9..MEUCIQDx..."
    }
  ]
}

Figure 1

4.3. Delegation Lifecycle

A delegation record transitions through four phases during its lifecycle:¶

Delegation Proposal Phase: The delegating agent creates a delegation proposal that includes the delegatee identity, the delegated scope, and, when structured policy is used, the delegated policy and operation context.¶
Delegation Interaction Phase (CONDITIONAL): When the Authorization Server determines that user interaction is required before the delegation can be authorized (for example, when delegating to a new agent for the first time, when the delegation involves high-risk operations, or when the delegation crosses trust domain boundaries), the AS returns an interaction_required response (see Section 5). A similar interaction response mechanism for the JWT Authorization Grant is described in [I-D.parecki-oauth-jwt-grant-interaction-response]. The delegating agent launches the interaction URI so the user can review and approve the delegation. Upon user approval, the agent retries the delegation request. This phase is skipped when the AS determines that no additional user interaction is needed (e.g., the delegation is covered by a standing authorization or the policy has been pre-approved). Implementations that do not require user interaction MAY omit this phase entirely.¶
Delegation Enforcement Phase: The Authorization Server validates the delegation request, verifies the delegator's token, confirms that any required user interaction has been completed, and signs the delegation record upon successful validation. For the first delegation (User to Agent A), the AS MAY additionally verify the user's identity using an identity assertion grant ([I-D.ietf-oauth-identity-assertion-authz-grant]).¶
Chain Propagation Phase: The signed delegation record is embedded into an access token's delegation_chain claim, enabling multi-hop propagation within or across trust domains.¶

This four-phase model ensures cryptographic binding between user authorization, agent identity, and policy constraints throughout the delegation chain, with explicit user interaction support when required.¶

4.4. Field Definitions

Table 1: delegation_chain Record Fields
Field	Type	Requirement	Description
delegator_id	string	REQUIRED	A URI identifying the delegating agent. This specification defines two URI schemes: `wit://` (WIT URI) and `spiffe://` (SPIFFE ID). The URI MUST be resolvable to a verifiable public key for `delegator_signature` verification.
delegatee_id	string	REQUIRED	A URI identifying the receiving agent. The same URI scheme considerations as `delegator_id` apply.
delegation_timestamp	NumericDate	REQUIRED	When this delegation was authorized.
scope	string	OPTIONAL	The delegated scope at this hop, expressed as a space-delimited list of scope values ([RFC6749], Section 3.3). When present, this field captures the scope explicitly authorized by the delegator and is included in the signature computation to prevent scope expansion by a compromised AS. When omitted, the delegated scope is conveyed through the access token's `scope` claim and the `delegated_policy` field (if present).
delegated_policy	object	OPTIONAL	A machine-readable expression of the authorization constraints that apply to this delegation hop. The delegated policy MUST be equal to or more restrictive than the delegator's policy; policy or scope expansion is not allowed. See below for deployment-specific structure.
operation_summary	string	OPTIONAL	Human-readable description of delegated operation.
root_evidence_ref	string	CONDITIONAL	An opaque identifier referencing the root authorization event (the original consent granted by the human principal from which all delegations in the chain derive). This field MUST be present for the first delegation (User to Agent A) when structured evidence is used and SHOULD be propagated through the chain. The format of the identifier and the mechanism for resolving it are deployment-specific: implementations using a structured authorization evidence model (such as the one described in [I-D.liu-oauth-authorization-evidence]) SHOULD set this value to the `evidence.id` from the root token; other deployments MAY use any stable, unique identifier (e.g., a consent record ID or an audit log entry reference) that enables post-hoc retrieval of the original authorization context. Implementations not using structured authorization evidence MAY omit this field.
delegator_signature	string	RECOMMENDED	Cryptographic signature from the delegating agent's private key over this delegation record. This provides dual-signature security alongside `as_signature`, preventing a malicious AS from forging unauthorized delegations and ensuring non-repudiation. Implementations SHOULD include this field on every delegation record. It MAY be omitted when the AS is the sole trust anchor and the deployment does not require independent delegator non-repudiation.
as_id	string	REQUIRED	An identifier for the Authorization Server that created this delegation record. This value MUST match the `iss` claim of the token in which this record first appeared. In cross-domain chains where records may originate from different Authorization Servers, the `as_id` enables the Resource Server to select the correct public key for `as_signature` verification.
as_signature	string	RECOMMENDED	AS signature over this delegation record. When all delegation hops occur within a single trust domain under one Authorization Server, the AS's signature over the issued token already attests to the entire chain and this per-hop signature MAY be omitted. It is RECOMMENDED when delegation crosses trust domain boundaries, so the receiving domain can independently verify each hop.

The structure of the delegated_policy field depends on the deployment profile:¶

Scope-based (typical): This field is typically absent. The delegation is governed solely by the OAuth scope parameter, and the Resource Server applies scope-based authorization. When this field is absent, the Resource Server MUST apply scope-based authorization only.¶
Structured policy: This field carries a machine-enforceable policy. The policy language and comparison mechanism are implementation-specific: implementations MAY use a Rego policy structure (with type, content, and entry_point sub-fields, as described in [I-D.liu-oauth-rego-policy]).¶

The delegation_timestamp MUST satisfy the following constraints:¶

It MUST be less than or equal to the access token's iat (issued at) claim, since the delegation event occurs before or at the time the token is issued;¶
It MUST be greater than or equal to the delegation_timestamp of the temporally earlier delegation record (the record at the next higher array index), ensuring that timestamps are monotonically non-increasing from index 0 (most recent) to index N (earliest);¶
It MUST be within the validity period of the delegator's token at the time of the delegation request (i.e., greater than or equal to the delegator token's iat and less than or equal to the delegator token's exp).¶
At the time the AS processes the delegation request, the timestamp SHOULD be within an acceptable freshness window relative to the AS's current time. A RECOMMENDED maximum skew is 5 minutes in either direction. Timestamps outside this window SHOULD be rejected to mitigate replay attacks (see Section 10).¶

The as_signature and delegator_signature, when present, MUST be computed over the same set of fields. The signature is a JWS ([RFC7515]) compact serialization. The JWS payload is a JSON object containing exactly the following fields (omitting OPTIONAL fields that are absent):¶

delegator_id¶
delegatee_id¶
as_id¶
delegation_timestamp¶
scope (if present)¶
delegated_policy (if present)¶
operation_summary (if present)¶
root_evidence_ref (if present)¶

Both signature fields MUST be excluded from their respective signature computations. The JWS alg header MUST be set appropriately (e.g., RS256 for AS signatures, ES256 for delegator signatures). The JWS kid header SHOULD be included to facilitate key resolution. The resulting compact JWS string is stored as the value of the respective signature field. When verifying, the verifier decodes the JWS payload and confirms that the decoded JSON object matches the delegation record fields.¶

When the delegator_signature is present (RECOMMENDED), it uses the delegating agent's agent-identifier-bound private key, while as_signature uses the Authorization Server's signing key. This dual-signature approach, when both signatures are present, ensures:¶

Malicious AS Prevention: A compromised AS cannot unilaterally forge delegations without the delegator's consent;¶
Non-Repudiation: The delegator cannot deny having authorized the delegation;¶
Complete Trust Chain: User → AS → Delegator → Delegatee.¶

The need for per-hop signatures depends on deployment scope. When all delegation hops occur within a single trust domain under one Authorization Server, the AS's signature over the issued token already attests to the entire delegation chain, and per-hop as_signature and delegator_signature MAY be omitted without loss of integrity. Per-hop signatures become valuable when delegation crosses trust domain boundaries — where the receiving domain must independently verify each hop's authorization — or when non-repudiation from the delegator is required for compliance or audit. This scoping keeps the mechanism lightweight for intra-domain deployments while preserving strong guarantees for cross-domain agent delegation.¶

4.5. Key Resolution for Agent Identifiers

The delegator_signature (and any verification of the delegatee's identity) requires the relying party to resolve the agent identifier to a verifiable public key. The resolution mechanism depends on the URI scheme used in the delegator_id or delegatee_id field:¶

wit://: The WIT URI is resolved via the workload identity provider's attestation bundle, which contains or references the agent's public key (e.g., via SPIFFE bundle endpoints);¶
spiffe://: The SPIFFE ID is resolved via the SPIFFE Bundle Endpoint protocol, which provides the agent's X.509-SVID or JWT-SVID containing the public key.¶

Implementations SHOULD document the supported URI schemes and their resolution mechanisms in deployment-specific configuration. If the relying party cannot resolve the agent identifier to a trusted public key, it MUST treat the delegator_signature as unverifiable.¶

4.6. Chain Ordering

The array MUST be ordered from most recent delegation to earliest:¶

Index 0: Most recent delegation (delegator → current token holder)¶
Index N: Earliest delegation (first agent after human authorization)¶

This ordering allows efficient validation starting from the immediate delegator.¶

5. Delegation with User Interaction

This section defines the delegation flow with explicit user interaction, used when the Authorization Server determines that user consent is required before delegation. It defines the interaction response mechanism for OAuth 2.0 Token Exchange requests ([RFC8693], grant_type=token-exchange). A similar mechanism for the JWT Authorization Grant ([RFC7523], grant_type=jwt-bearer) is described in [I-D.parecki-oauth-jwt-grant-interaction-response].¶

The user interaction mechanism ensures that delegation decisions remain under user control even in complex multi-agent scenarios. When the Authorization Server determines that user interaction is required, the flow includes an explicit consent step before token issuance.¶

+--------+       +---------+       +--------+       +---------+       +---------+
|  User  |       | Agent A |       |   AS   |       | Agent B |       |   RS    |
+--------+       +---------+       +--------+       +---------+       +---------+
    |                 |                 |                |                 |
    | (1) Initial     |                 |                |                 |
    |  Authorization  |                 |                |                 |
    |  (OAuth flow)   |                 |                |                 |
    |---------------> |                 |                |                 |
    |                 |                 |                |                 |
    |                 | (2) Token A     |                |                 |
    |                 |  (root, no      |                |                 |
    |                 |   chain)        |                |                 |
    |                 |<----------------|                |                 |
    |                 |                 |                |                 |
    |                 | (3) Token Exchange (delegation)  |                 |
    |                 |---------------->|                |                 |
    |                 |  - subject_token                 |                 |
    |                 |  - delegatee_id                  |                 |
    |                 |  - authorization_details         |                 |
    |                 |                 |                |                 |
    |                 | (4) AS determines user interaction required        |
    |                 |     interaction_required         |                 |
    |                 |     interaction_uri              |                 |
    |                 |     interval=5                   |                 |
    |                 |<----------------|                |                 |
    |                 |                 |                |                 |
    | (5) Launch      |                 |                |                 |
    |  interaction    |                 |                |                 |
    |<----------------|                 |                |                 |
    |                 |                 |                |                 |
    | (6) Review &    |                 |                |                 |
    |  Approve        |                 |                |                 |
    |  delegation     |                 |                |                 |
    |---------------------------------->|                |                 |
    |                 |                 |                |                 |
    |                 | (7) Redirect    |                |                 |
    |                 |<----------------|                |                 |
    |                 |                 |                |                 |
    |                 | (8) Retry Token Exchange         |                 |
    |                 |---------------->|                |                 |
    |                 |                 |                |                 |
    |                 |                 | (9) Validate   |                 |
    |                 |                 | - Interaction  |                 |
    |                 |                 |   completed    |                 |
    |                 |                 | - Token A valid|                 |
    |                 |                 | - Scope subset |                 |
    |                 |                 |                |                 |
    |                 |                 | (10) Issue Token B               |
    |                 |<----------------|                |                 |
    |                 |  with delegation_chain           |                 |
    |                 | (10.5) Transfer to Agent B       |                 |
    |                 |--------------------------------->|                 |
    |                 |                 |                |                 |
    |                 |                 |                | (11) API Request|
    |                 |                 |                |---------------->|
    |                 |                 |                |                 |
    |                 |                 |                |  (12) Validate  |
    |                 |                 |                |   chain         |
    |                 |                 |                |<----------------|

Figure 2

5.1. Step 1-2: Initial Authorization

Agent A obtains authorization from the user through a standard OAuth flow. The resulting token does not contain a delegation_chain (it is the root authorization).¶

5.2. Step 3: Delegation Request

Agent A initiates delegation using OAuth 2.0 Token Exchange [RFC8693]. The request includes delegation-specific parameters to identify the delegatee and the delegated policy.¶

The following example shows a delegation request with WIT-based agent identity, client attestation, and a structured policy carried via authorization_details:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJ3aXQrand0IiwiYWxnIjoiRVMyNTYifQ...
OAuth-Client-Attestation-PoP: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0...

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=eyJhbGciOiJSUzI1NiJ9...
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
&scope=cart%3Aread
&authorization_details=%5B%7B%22type%22%3A%22rego_policy%22%2C%22policy%22
  %3A%7B%22type%22%3A%22rego%22%2C%22content%22%3A%22package+agent...%22%2C
  %22entry_point%22%3A%22allow%22%7D%7D%5D
&delegatee_id=wit%3A%2F%2Fagent-b.example%2Fsha256.bbb222...

Figure 3

This specification defines the following extension parameter for use with Token Exchange [RFC8693] requests:¶

delegatee_id:: REQUIRED for delegation requests. A URI identifying the agent receiving the delegated authorization. Implementations SHOULD use a WIT URI when workload identity attestation is available, but MAY use other URI schemes (see Table 1). The AS uses this value to bind the issued token to the delegatee's identity and to populate the delegatee_id field in the delegation_chain record.¶

The standard and extension parameters in the request are:¶

subject_token: Agent A's current access token;¶
subject_token_type: urn:ietf:params:oauth:token-type:access_token;¶
authorization_details (OPTIONAL): Carries the delegated policy in a structured format (e.g., type "rego_policy"), which MUST be equal to or more restrictive than Agent A's policy;¶
delegatee_id: The agent identifier URI of the delegatee agent (Agent B);¶
scope (OPTIONAL): Requested scope for the delegated token, which MUST be a subset of Agent A's scope.¶
requested_token_type (OPTIONAL): Defaults to urn:ietf:params:oauth:token-type:jwt. Because the delegation_chain claim MUST be embedded in a JWT, implementations using this specification MUST request JWT-format access tokens. The value urn:ietf:params:oauth:token-type:jwt is REQUIRED when the delegation_chain claim is expected in the response.¶
resource (OPTIONAL): The identifier of the target Authorization Server when the delegation crosses a trust domain boundary, as defined in [I-D.ietf-oauth-identity-chaining]. When present, the AS issues a JWT authorization grant suitable for presentation to the target AS instead of a direct access token.¶
audience (OPTIONAL): A well-known or logical name of the target Authorization Server, as an alternative to resource for cross-domain delegation. One of resource or audience is REQUIRED when the delegation targets an agent in a different trust domain.¶
interaction_callback_uri (OPTIONAL): The URI to which the AS will redirect the user's browser after a delegation interaction is complete, as specified in Section 5.3. A similar parameter is described in [I-D.parecki-oauth-jwt-grant-interaction-response]. This parameter is used in conjunction with the interaction_required response to signal the client that user interaction has been completed.¶

5.3. Step 4: User Interaction Required

When the Authorization Server determines that user interaction is required (see Section 5.9 for the decision criteria), the AS responds with an interaction_required error containing:¶

interaction_uri: The URI where the user reviews and approves the delegation;¶
interval: The minimum polling interval in seconds (default: 5);¶
expires_in: The number of seconds until the interaction session expires.¶

This specification defines the interaction response mechanism for delegation Token Exchange requests ([RFC8693], grant_type=token-exchange). A similar mechanism for the JWT Authorization Grant (RFC 7523, grant_type=jwt-bearer) is described in [I-D.parecki-oauth-jwt-grant-interaction-response]. The response semantics defined here are applicable to Token Exchange requests. The AS associates the interaction session with the Token Exchange request parameters (including the subject_token, delegatee_id, and requested delegation policy) so that upon user approval, the same Token Exchange request can be retried to obtain the delegated token.¶

5.4. Steps 5-7: User Review and Approval

Agent A launches the interaction_uri in the user's browser, where the AS presents the delegation details for user review:¶

Identity of the delegatee agent (Agent B)¶
Delegated policy and scope¶
Operation summary¶
Whether the delegation crosses trust domain boundaries¶

The user reviews the delegation details and approves or denies the delegation request. If the client provided an interaction_callback_uri, the AS redirects the user's browser to that URI as a signal that the interaction is complete.¶

5.5. Step 8: Retry Token Exchange

Agent A retries the original Token Exchange request (with the same parameters). The AS recognizes the associated interaction session and proceeds with validation.¶

While the interaction is pending, subsequent Token Exchange requests from Agent A with the same parameters SHOULD return an interaction_pending error. The agent MUST wait at least the number of seconds specified by the interval parameter between polling requests.¶

5.6. Step 9: AS Validation

The AS MUST perform the following validations:¶

Interaction Completion (CONDITIONAL): When user interaction was required (see Section 5.3), verify that it has been completed and approved for this delegation request. This step is skipped when the AS determines that no user interaction is needed.¶
Token Validity: Verify Agent A's token is valid and not revoked.¶
Delegation Permission: Confirm the token permits delegation (e.g., includes a delegation scope or flag).¶
Scope Subset: Verify the requested scope is a subset of Agent A's authorized scope (equal to or narrower).¶
Delegatee Authentication: Validate Agent B's agent identifier (delegatee_id) to confirm the delegatee is authentic and currently active.¶
Chain Depth: Optionally enforce maximum delegation depth.¶
Upstream Chain Validation (CONDITIONAL): When the subject token contains a delegation_chain claim, verify the chain's continuity, signatures, and policy narrowing as defined in Section 9. If validation fails, reject the request with an invalid_delegation_chain error.¶
Request Freshness: Reject the delegation request if the delegation_timestamp in the proposal (or the request time as observed by the AS) is outside an acceptable time window. A RECOMMENDED maximum skew is 5 minutes. This prevents replay of previously captured delegation requests.¶

5.7. Step 10: Token Issuance

Upon successful validation, the AS issues a new token for Agent B with:¶

sub: The original user (unchanged)¶
act: Agent B's identity¶
delegation_chain: Extended with a new record for this hop¶
Reduced scope (as requested)¶

5.8. Steps 11-12: API Request and Validation

Agent B uses the delegated token to access resources at the Resource Server (RS). The RS validates the token and verifies the delegation_chain as defined in Section 9.¶

5.9. When to Require Interaction

The Authorization Server has discretion in determining when the Delegation Interaction Phase is triggered. The following guidance is provided to help AS implementations make consistent decisions:¶

First-time delegation to a new agent: When the delegatee agent has not been previously authorized by the user, interaction SHOULD be required to ensure the user is aware of and consents to the new delegation relationship.¶
High-risk operations: When the delegated policy includes operations classified as high-risk (e.g., financial transactions, data deletion, access to sensitive resources), interaction SHOULD be required regardless of whether the agent has been previously authorized.¶
Cross-domain delegation: When a delegation hop crosses a trust domain boundary, interaction SHOULD be required unless a pre-established cross-domain trust agreement covers the specific delegation pattern.¶
Standing authorization: When the user has previously granted a standing authorization that explicitly covers the delegation pattern (e.g., "Agent A may delegate inventory operations to any agent in the inventory.example.com domain"), interaction MAY be skipped.¶
Policy pre-approval: When the delegated policy is equal to or more restrictive than a previously user-approved policy for the same delegatee, interaction MAY be skipped.¶

7. Chain Extension

When the AS issues a delegated token, it extends the delegation_chain:¶

7.1. Evidence Propagation

When the AS issues a delegated token within the same trust domain and structured authorization evidence is used, it SHOULD propagate the evidence claim from the subject token (or root token) into the newly issued delegated token. This ensures that Resource Servers can verify the original user consent without needing to retrieve the root token separately. When evidence is propagated, the root_evidence_ref field in each delegation record SHOULD match the evidence.id value in the propagated evidence claim. For cross-domain evidence propagation, see Section 8.¶

Implementations not using structured authorization evidence are not required to carry evidence claims. In deployments that do not use structured authorization evidence, the root_evidence_ref field (when present) serves as an opaque reference to the original authorization event, resolvable through deployment-specific mechanisms such as an audit log query or a consent management API.¶

7.2. For First Delegation

If Agent A's token has no delegation_chain (root authorization), the AS creates a new chain with one entry. The following shows an extended first delegation record:¶

{
  "delegation_chain": [
    {
      "delegator_id": "wit://agent-a.example/sha256.aaa111...",
      "delegatee_id": "wit://agent-b.example/sha256.bbb222...",
      "as_id": "https://as.example.com",
      "delegation_timestamp": 1734516900,
      "root_evidence_ref": "evidence-root-abc123",
      "delegated_policy": {
        "type": "rego",
        "content": "package agent\ndefault allow = false\n\nallow if {\n  input.action == \"cart_op\"\n}",
        "entry_point": "allow"
      },
      "operation_summary": "Delegate cart operations",
      "delegator_signature": "eyJhbGciOiJFUzI1NiJ9..MEYCIQD...",
      "as_signature": "eyJhbGciOiJSUzI1NiJ9..MEUCIQDx..."
    }
  ]
}

Figure 5

A minimal equivalent would carry only delegator_id, delegatee_id, as_id, delegation_timestamp, operation_summary, and as_signature, with the delegated scope expressed via the token's scope claim (e.g., cart:read).¶

7.3. For Subsequent Delegations

If Agent B further delegates to Agent C, the AS prepends a new record. The following shows an extended two-hop chain:¶

{
  "delegation_chain": [
    {
      "delegator_id": "wit://agent-b.example/sha256.bbb222...",
      "delegatee_id": "wit://agent-c.example/sha256.ccc333...",
      "as_id": "https://as.example.com",
      "delegation_timestamp": 1734517800,
      "root_evidence_ref": "evidence-root-abc123",
      "delegated_policy": {
        "type": "rego",
        "content": "package agent\ndefault allow = false\n\nallow if {\n  input.action == \"inventory_check\"\n  input.item_id == \"123\"\n}",
        "entry_point": "allow"
      },
      "operation_summary": "Check inventory for item 123",
      "delegator_signature": "eyJhbGciOiJFUzI1NiJ9..MEYCIQD...",
      "as_signature": "eyJhbGciOiJSUzI1NiJ9..MEUCIQDx..."
    },
    {
      "delegator_id": "wit://agent-a.example/sha256.aaa111...",
      "delegatee_id": "wit://agent-b.example/sha256.bbb222...",
      "as_id": "https://as.example.com",
      "delegation_timestamp": 1734516900,
      "root_evidence_ref": "evidence-root-abc123",
      "delegated_policy": {
        "type": "rego",
        "content": "package agent\ndefault allow = false\n\nallow if {\n  input.action == \"cart_op\"\n}",
        "entry_point": "allow"
      },
      "operation_summary": "Delegate cart operations",
      "delegator_signature": "eyJhbGciOiJFUzI1NiJ9..MEYCIQD1...",
      "as_signature": "eyJhbGciOiJSUzI1NiJ9..MEUCIQDx..."
    }
  ]
}

Figure 6

With scope-based delegation, the same two-hop chain would omit delegated_policy, delegator_signature, and root_evidence_ref from each record. The scope narrowing (e.g., cart:read inventory:read to inventory:read:item:123) is expressed solely via each delegated token's scope claim.¶

8. Cross-Domain Delegation

When delegation hops span multiple trust domains (each with its own Authorization Server), this specification combines the delegation_chain mechanism with the cross-domain transport pattern defined in [I-D.ietf-oauth-identity-chaining].¶

The grant type used for delegation depends on the trust domain boundary:¶

Single-domain delegation: Uses OAuth 2.0 Token Exchange ([RFC8693], grant_type=token-exchange) as defined in Section 6. Both delegator and delegatee agents trust the same Authorization Server, which can validate the subject token and issue a delegated token directly.¶
Cross-domain delegation: Combines Token Exchange ([RFC8693]) at the originating AS with the JWT Bearer Grant ([RFC7523], grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer) at the receiving AS. When agents belong to different trust domains with different Authorization Servers, the originating AS cannot issue a direct access token for the remote domain. Instead, the delegating agent initiates a Token Exchange request at the originating AS, which returns a signed JWT authorization grant. The delegatee agent then presents this grant to its local AS using the JWT Bearer grant type. The receiving AS verifies the grant using the originating AS's public key (obtained via [RFC8414] metadata) and issues a local access token.¶

8.1. Cross-Domain Delegation Flow

Consider an agent in Trust Domain A that needs to delegate a subset of its authorization to an agent in Trust Domain B:¶

+-------+  +-------+  +-------+  +-------+  +-------+       +-------+
| User  |  |Agent A|  | AS-A  |  |Agent B|  | AS-B  |       | RS-B  |
+-------+  +-------+  +-------+  +-------+  +-------+       +-------+
     |          |          |          |          |              |
     | (1) Auth |          |          |          |              |
     |--------->|          |          |          |              |
     |          |          |          |          |              |
     |          | (2) Token Exchange  |          |              |
     |          |  (delegation +      |          |              |
     |          |   resource=AS-B)    |          |              |
     |          |--------->|          |          |              |
     |          |          |          |          |              |
     |          | (3) JWT  |          |          |              |
     |          | Authoriz |          |          |              |
     |          | Grant    |          |          |              |
     |          |<---------|          |          |              |
     |          |          |          |          |              |
     |          | (3.5) Agent A transfers JWT Grant to Agent B  |
     |          |-------------------->|          |              |
     |          |          |          |          |              |
     |          |          |          | (4) Present JWT Grant   |
     |          |          |          |--------->|              |
     |          |          |          |          |              |
     |          |          |          |          |(5) Validate  |
     |          |          |          |          |- JWT signature|
     |          |          |          |          |- delegation  |
     |          |          |          |          |- policy      |
     |          |          |          |          |              |
     |          |          |          |          |(6) Access    |
     |          |          |          |          |  Token       |
     |          |          |          |<---------|              |
     |          |          |          |          |              |
     |          |          |          |(7) API Req              |
     |          |          |          |------------------------>|
     |          |          |          |          |              |

Figure 7

Agent A obtains initial authorization from the user in Trust Domain A (root authorization, no delegation_chain).¶
Agent A initiates a delegation Token Exchange with AS-A, including the resource parameter set to AS-B's identifier (as defined in [I-D.ietf-oauth-identity-chaining]) and the delegatee_id parameter identifying Agent B. This signals that the delegation targets an agent in Trust Domain B.¶
AS-A validates the delegation, creates a delegation record, and returns a JWT authorization grant containing the delegation_chain claim. If user interaction is required, the interaction flow described in Section 5 is used before this step.¶
Agent A transfers the JWT authorization grant to Agent B through an out-of-band mechanism (e.g., a secure internal channel).¶
Agent B presents the JWT authorization grant to AS-B using the JWT Bearer grant type ([RFC7523]), as defined in [I-D.ietf-oauth-identity-chaining].¶
AS-B validates the JWT grant signature, verifies the delegation_chain (including AS-A's signature on each record), and confirms policy narrowing constraints.¶
AS-B issues an access token to Agent B for Trust Domain B, preserving the delegation_chain claim from the JWT authorization grant.¶
Agent B uses the access token to access resources in Trust Domain B.¶

8.2. Cross-Domain Trust Requirements

For cross-domain delegation to function, the following trust requirements MUST be satisfied:¶

AS Trust Relationship: AS-B MUST trust AS-A's signing key to verify as_signature on delegation records issued by AS-A. This trust relationship is typically established through key exchange or by publishing AS-A's public keys via Authorization Server Metadata ([RFC8414]).¶
delegation_chain Propagation: AS-B MUST propagate the delegation_chain claim from the JWT authorization grant into the access token it issues, so that Resource Servers in Trust Domain B can validate the full delegation lineage.¶
Evidence Propagation: AS-B SHOULD propagate the evidence claim from the JWT authorization grant, enabling Resource Servers in Trust Domain B to verify the original user consent without contacting AS-A. This is a SHOULD rather than a MUST because cross-domain evidence propagation may be constrained by data minimization policies, privacy regulations, or trust agreements between domains. When evidence is not propagated, Resource Servers in Trust Domain B MUST rely on back-channel verification with AS-A or AS-B to validate the original user consent.¶
Policy Enforcement: AS-B MUST enforce that the delegated scope is equal to or narrower than the scope in the JWT authorization grant; scope expansion across domain boundaries is not permitted. When the delegated_policy field is present, AS-B SHOULD additionally verify that the policy has not been expanded. The mechanism for policy comparison is implementation- specific: for simple policy representations, a structural comparison may suffice; for expressive policy languages such as Rego or ALFA, the receiving AS MAY rely on the originating AS's attestation (via as_signature) rather than performing an independent policy-subset check, which may be computationally intractable for arbitrary policies.¶

8.3. Multi-Domain Chain Extension

When a delegation chain spans multiple domains, each domain's AS may add delegation records to the chain. The cross-domain transport uses the identity chaining pattern (Token Exchange + JWT Bearer Grant) at each domain boundary, while the delegation_chain accumulates records from all domains.¶

Resource Servers validating a cross-domain delegation chain MUST:¶

Verify as_signature on each delegation record using the signing key of the AS identified by the record's as_id field (which may differ across records);¶
Verify trust relationships between all ASes referenced in the chain;¶
Verify chain continuity and policy narrowing across domain boundaries.¶

8.4. Claims Transcription for Delegation

Section 2.5 of [I-D.ietf-oauth-identity-chaining] describes Claims Transcription (the process by which Authorization Servers add, change, or remove claims during cross-domain token flows) but leaves the representation of transcribed claims undefined. The delegation_chain claim provides one such representation: when delegation crosses a trust domain boundary, each delegation record captures the transcribed policy (when present, delegated_policy), the identity mapping (delegator and delegatee identifiers), and the cryptographic evidence of both the transcribing AS (as_signature) and, when present, the delegating agent (delegator_signature).¶

This enables the receiving domain's AS (AS-B) to verify not just what claims were transcribed but who authorized the transcription and under what constraints, closing the representation gap left by the base identity chaining specification. AS-B SHOULD validate the delegation_chain records from AS-A as part of its Claims Transcription processing before issuing a local access token.¶

9. Resource Server Validation

Resource Servers validate the delegation_chain as follows:¶

9.1. Signature Verification

For each record in the chain, verify the as_signature, when present, using the public key of the AS identified by the record's as_id field. In single-domain chains, as_id matches the token's iss claim. In cross-domain chains, different records may carry different as_id values, and the Resource Server MUST select the corresponding AS public key for each record. In cross-domain chains, the Resource Server does not need to verify that upstream records' as_id values match the current token's iss claim; the as_id is used solely to select the correct public key for as_signature verification. When the as_signature is present, verification ensures:¶

The delegation was authorized by the AS;¶
The record has not been tampered with;¶
The delegation metadata is authentic.¶

When as_signature is omitted on a record, the record's integrity is still protected by the token-level JWT signature, which covers the entire delegation_chain claim as a single unit. Omitting as_signature is typical in single-domain deployments where the token issuer's signature already attests to every record; per-record as_signature is RECOMMENDED in cross-domain or multi-AS deployments where independent per-hop attestation adds assurance.¶

9.2. Root Authorization Anchor

The last record in the chain (highest index) represents the earliest delegation. Its delegator_id identifies the agent that holds the root authorization (the token directly authorized by the user).¶

The Resource Server SHOULD verify the root authorization anchor. Since the RS typically observes only the delegated token (which carries the delegation_chain), it does not have direct access to the root token. Verification can be performed through one or more of the following means:¶

Using token introspection ([RFC7662]) to confirm that the earliest delegator (identified by the delegator_id of the last chain record) holds a valid, non-revoked root token issued by a trusted AS;¶
Relying on the structural integrity of the delegation_chain itself: the AS that issued the delegated token has already verified the root token's validity at issuance time, and, when present, the as_signature on each record attests to that verification. Even without per-record as_signature, the token-level JWT signature covers the entire delegation_chain array, binding the issuance attestation to the token as a whole.¶

In deployments using structured authorization evidence, the Resource Server SHOULD additionally verify that the root token contains a valid evidence claim (as described in [I-D.liu-oauth-authorization-evidence] or an equivalent structured evidence model), providing cryptographic proof of user consent. Deployments that do not carry structured evidence MAY rely on the root_evidence_ref field as an opaque pointer to the original authorization event, resolvable through deployment-specific mechanisms.¶

If the RS cannot establish confidence in the root authorization anchor through any available mechanism, it SHOULD reject the request.¶

9.3. Dual-Signature Verification

For each delegation record, when the as_signature field is present, the Resource Server SHOULD verify it using the Authorization Server's public key. When the delegator_signature field is present, the Resource Server SHOULD additionally verify it using the delegating agent's public key (resolved as described in the Key Resolution section above). In single-domain deployments where the token issuer's JWT signature already covers every record, per-record as_signature verification is not required; the token-level signature provides sufficient integrity.¶

AS Signature (SHOULD when present): Confirms the delegation was authorized by the AS and the record has not been tampered with;¶
Delegator Signature (SHOULD when present): Confirms the delegator explicitly consented to this delegation, providing non-repudiation.¶

When both signatures are present and verified, the dual-signature mechanism prevents:¶

A malicious AS from unilaterally forging delegations;¶
Delegators from denying authorized delegations (non-repudiation);¶
Unauthorized privilege escalation through compromised components.¶

Deployments that rely solely on as_signature accept the AS as the single trust anchor for delegation records. This is appropriate when the AS is operated by a trusted authority and the deployment does not require independent delegator non-repudiation.¶

Deployments that omit as_signature on some or all records rely on the token-level JWT signature as the sole integrity mechanism for the delegation_chain array. This is appropriate in single-domain deployments where one AS issues the token and attests to every delegation record through its token-level signature; it is also the minimal configuration that retains chain integrity, tamper detection, record removal detection, and reorder detection, as those properties are enforced by the token-level signature covering the array as a whole.¶

9.4. Agent Identifier Status Validation

The Resource Server SHOULD verify the current status of all agent identifiers referenced in the delegation_chain. The verification mechanism depends on the identifier scheme:¶

WIT URIs (wit://, spiffe://): Check WIT revocation lists or status endpoints, validate expiration timestamps, or query the issuing identity provider for current status.¶

If any agent identifier in the chain has been revoked or its associated key material has expired, the entire delegation_chain MUST be considered invalid, even if individual records remain cryptographically valid.¶

9.5. Chain Continuity

Verify the chain is continuous:¶

For each record at index i (where i > 0), record[i].delegatee_id MUST equal record[i-1].delegator_id, ensuring that the agent who received authorization in one hop is the same agent that delegates in the next hop;¶
The delegatee_id of the most recent delegation record (index 0) matches the token's act.sub;¶
Timestamps are in descending order.¶

9.6. Scope and Policy Validation

The Resource Server validates that authorization constraints have not been expanded along the chain:¶

Scope (MUST): The scope of each delegated token MUST be equal to or a subset of the scope of the preceding token in the chain. The final token's scope MUST cover the requested operation. Scope expansion at any hop invalidates the chain.¶
Policy (CONDITIONAL): When the delegated_policy field is present, the Resource Server SHOULD verify that each hop's policy is equal to or more restrictive than its predecessor's policy. The mechanism for this comparison is implementation- specific. For expressive policy languages where automated subset checking is computationally expensive or undecidable, the RS MAY rely on the AS's attestation (as_signature) as evidence that the AS already performed policy narrowing validation at issuance time.¶

10. Security Considerations

The security considerations of [RFC8693] and [RFC7519] apply to this specification. The following considerations follow the guidelines in [RFC3552].¶

10.1. Threat Model

This section describes the threat model underlying the delegation_chain mechanism and the security properties it provides.¶

Trusted Entities:¶

The Authorization Server (AS) is trusted to correctly validate delegation requests, enforce policy narrowing, and sign delegation records with its private key. The AS is the central trust anchor for the delegation chain.¶
The human principal (end user) is trusted to make informed authorization decisions during consent and interaction flows.¶

Adversary Capabilities:¶

A malicious delegatee agent may attempt to present a token with a forged or truncated delegation_chain to claim authorization it does not possess.¶
A malicious delegator agent may attempt to delegate more authorization than it was granted (privilege escalation), or may deny having authorized a delegation (repudiation).¶
A compromised AS may attempt to forge delegation records without the delegator's consent. When the dual-signature mechanism (delegator + AS) is used, it mitigates this threat; deployments that rely solely on as_signature accept the AS as the sole trust anchor and must ensure AS compromise detection through other operational controls.¶
A network attacker may attempt to intercept or modify delegation records in transit. Standard TLS protections apply to all protocol messages.¶
A token thief may attempt to steal a delegated access token (e.g., by compromising an agent's storage, intercepting a token in transit, or exploiting a side-channel) and present it to a Resource Server as if it were the legitimate delegatee. The thief may also attempt to replay a previously captured delegation request to obtain a new token.¶
A credential thief may attempt to steal an agent's workload identity credentials (e.g., WIT signing key, SPIFFE SVID, or client attestation key material) and impersonate the agent to obtain unauthorized delegations from the AS. This threat is particularly severe in multi-hop chains, where a single compromised agent identity can be used to initiate new delegation paths.¶

Security Objectives: The delegation_chain claim provides the following security properties:¶

Integrity: Each delegation record is cryptographically signed by the AS (and, when present, the delegator), preventing undetected modification.¶
Non-repudiation (CONDITIONAL): When the delegator_signature is present, it provides independent evidence that the delegation was explicitly authorized by the delegator. When omitted, deployments rely on AS audit logs for non-repudiation.¶
Scope compliance: Mandatory scope narrowing at each hop prevents privilege escalation through the chain. When the delegated_policy field is present, policy narrowing provides additional fine-grained enforcement.¶
Auditability: The complete chain from the current actor back to the original human principal enables end-to-end audit trail reconstruction.¶

10.2. Privilege Escalation Prevention

The AS MUST ensure that delegation cannot expand privileges:¶

Delegated scope MUST be a subset of (equal to or narrower than) delegator's scope;¶
Delegation depth MAY be limited;¶
Certain scopes MAY be marked non-delegatable.¶

10.3. Chain Integrity

Chain integrity is primarily ensured by the token-level JWT signature, which covers the entire delegation_chain claim as a single unit. When the per-record as_signature is present, it provides an additional layer of per-hop attestation. Together, these mechanisms enforce chain integrity through the following properties:¶

Forgery prevention: Agents cannot forge delegation records. The token-level JWT signature requires the AS's private signing key, which agents do not possess; when as_signature is present, it adds an independent per-record attestation that also requires the AS's key.¶
Tamper detection: Agents cannot modify existing records because any change to the signed fields (including delegator_id, delegatee_id, scope, and delegated_policy) invalidates the token-level JWT signature, and, when present, the record-level as_signature as well.¶
Record removal detection: Agents cannot remove records from the chain because the token-level JWT signature covers the entire delegation_chain claim as a single unit; any modification to the array length or contents invalidates the token signature.¶
Reorder detection: Agents cannot reorder records because the token-level JWT signature covers the delegation_chain array in its exact serialized form; any reordering invalidates the token signature.¶

The four properties above hold for every deployment, including the minimal single-domain configuration in which as_signature is omitted on all records. Adding per-record as_signature in cross-domain or multi-AS deployments strengthens forgery prevention and tamper detection by providing independent per-hop attestation that survives token re-issuance.¶

Additionally, the Resource Server SHOULD verify that the delegation_timestamp on each record falls within a reasonable window relative to the token's iat (issued-at) claim. Timestamps that significantly predate the token's issuance or fall in the future may indicate a manipulated or replayed delegation record.¶

10.4. Chain Stripping Prevention

A malicious agent may attempt to present a token with a truncated or empty delegation_chain to hide intermediate delegation hops. For example, an agent holding a token with chain [A→B→C] (three records: C←B, B←A, User→A) could attempt to present only the most recent record [C←B] or an empty chain, thereby concealing the earlier hops from the Resource Server.¶

This attack is prevented by the following mechanisms:¶

Token-level signature: The AS signs the entire access token (including the delegation_chain claim) using its private key. Any modification to the delegation_chain claim (including removal of records or replacement with a shorter chain) invalidates the token's signature. The Resource Server MUST reject tokens whose signature does not verify.¶

For opaque (non-JWT) access tokens, the Resource Server MUST use token introspection ([RFC7662]) to retrieve the authoritative delegation_chain from the AS, rather than trusting any client-supplied chain data.¶

10.5. Confidentiality of Delegation Records

A delegation chain may contain privacy-sensitive information and, to prevent disclosure to unintended parties, should only be transmitted over encrypted channels, such as Transport Layer Security (TLS). All claims in a signed but unencrypted JWT (JWS, [RFC7515]) are Base64URL-encoded and readable by any party that obtains the token, including the full delegation topology (all agent identities), business policy logic (delegated_policy), operation descriptions (operation_summary), and authorization event references (root_evidence_ref).¶

In cases where it is desirable to prevent disclosure of delegation records to unintended parties, the JWT should be encrypted using JWE ([RFC7516]) with nested JWT processing (JWE(JWS(payload))), so that only the intended Resource Server can read the delegation chain contents. In cross-domain deployments, JWE encryption or the chain-by-reference pattern (see below) should be used to prevent downstream domains from reading upstream delegation records.¶

Deployments should determine the minimum amount of information necessary for delegation validation and include only such claims in delegation records. The operation_summary field should contain only the minimum text necessary for authorization decisions. The delegated_policy should be scoped to the specific operations being delegated. Agent identifiers (delegator_id, delegatee_id) can be pseudonymous WIT or SPIFFE URIs rather than human-readable names, as described in Section 6.3.1 of the OAuth Assertion Framework ([RFC7521]).¶

Additionally, implementations may use the delegation_chain_ref pattern (described in Section 10.7) to replace the inline chain with an opaque URI, retrieving the full chain via introspection ([RFC7662]) over a TLS-protected channel. The RECOMMENDED short token lifetime (5 to 15 minutes, see Section 10.6) limits the exposure window of any leaked delegation records.¶

10.6. Token Protection

Delegated tokens are subject to replay and theft attacks. The following mitigations address both threats.¶

Sender-constrained tokens: Implementations SHOULD bind issued access tokens to the delegatee's key material using one of the following mechanisms:¶

DPoP ([RFC9449]): The delegatee presents a proof-of-possession JWT alongside the access token. The Resource Server verifies that the DPoP proof's jkt thumbprint matches the key binding in the access token.¶
Mutual TLS (mTLS): The delegatee authenticates using a client certificate whose subject or SAN is bound to the delegatee_id in the delegation record.¶

When sender-constrained tokens are not used, the delegatee_id field alone provides only application-level binding. Deployments that accept this weaker binding SHOULD compensate with shorter token lifetimes and network-level controls.¶

Delegation request replay: An attacker replays a captured Token Exchange request to the AS to obtain a new delegated token. Mitigations include:¶

For the initial delegation hop, the AS enforces a freshness window on the subject_token's iat claim (RECOMMENDED skew: 5 minutes);¶
Sender-constrained tokens on the delegating agent's access token (e.g., DPoP ([RFC9449]) or OAuth-Client-Attestation) ensure that a replayed request from a different endpoint fails client authentication at the AS;¶
TLS protects all protocol messages from on-path capture.¶

Token replay and theft: An attacker presents a stolen delegated token to a Resource Server. Mitigations include:¶

Short token lifetimes (RECOMMENDED: 5 to 15 minutes) limit the window during which a stolen or replayed token remains valid;¶
Sender-constrained tokens (DPoP or mTLS) ensure that a stolen token cannot be used by a different party;¶
Token introspection ([RFC7662]) enables real-time revocation status checking;¶
Presenter verification: The Resource Server MUST verify that the presenter's authenticated identity matches delegatee_id of the most recent delegation record (index 0);¶
Revocation propagation: When theft is detected, the AS SHOULD revoke the compromised delegation hop, invalidating all downstream tokens (see Section 10.9).¶

Implementations SHOULD use sender-constrained tokens for both the delegation request and the issued delegated token, especially in multi-hop chains where a stolen token could grant access across multiple trust boundaries. The delegation_chain claim additionally enables post-incident forensic analysis by identifying the agents and timestamps at each hop.¶

10.7. Delegation Depth Limits

Implementations SHOULD enforce maximum delegation depth to:¶

Prevent unbounded delegation chains;¶
Limit token size growth;¶
Simplify validation.¶

A RECOMMENDED default maximum depth is 5 hops.¶

When a delegation request would exceed the configured maximum depth, the AS MUST reject the request with an OAuth 2.0 error response using the error code delegation_depth_exceeded and a human-readable error_description indicating the maximum delegation depth has been reached. If a Resource Server receives a token whose delegation_chain length exceeds its locally configured maximum depth, it SHOULD reject the request regardless of signature validity, as excessively deep chains may indicate a misconfigured or malicious delegation path.¶

Implementers should consider the impact of delegation chain depth on token size. Each delegation record typically adds 500 to 1000 bytes to the token payload, including one or two JWS signatures (approximately 200 bytes each for ES256) and, when present, the structured policy content. A 5-hop delegation chain may therefore add 2.5 to 5 KB to the access token. This can cause issues with:¶

HTTP header size limits (commonly 8 KB in default proxy configurations);¶
TLS record size constraints;¶
Client and server memory consumption during token parsing.¶

To mitigate token size growth, implementations MAY use one or more of the following strategies:¶

Short-lived tokens with introspection: Issue access tokens with short expiration and rely on token introspection ([RFC7662]) to retrieve the delegation_chain on demand;¶
Chain by reference: Instead of embedding the full delegation_chain in the JWT, issue a compact token carrying only a delegation_chain_ref (a URI pointing to the full chain stored at the AS). The Resource Server retrieves the chain via introspection or a dedicated endpoint. This approach keeps the token payload constant regardless of chain depth, at the cost of an additional round-trip for chain retrieval;¶
Policy references: Store policies in a shared policy store and embed only a reference (URI) in the delegated_policy field rather than the full policy content.¶

10.8. Cross-Domain Trust

When delegation chains span multiple trust domains, additional security considerations apply:¶

AS Key Trust and Record Attribution: Resource Servers in each trust domain must be able to verify as_signature on delegation records issued by Authorization Servers in other trust domains. Each delegation record carries an as_id field that identifies the AS that created it, enabling the Resource Server to select the correct public key for signature verification. When delegation records cross a domain boundary, the receiving AS preserves the upstream records with their original as_id and as_signature values intact. To obtain the public key for a given as_id, the Resource Server uses Authorization Server Metadata ([RFC8414]), a shared trust framework, or deployment-specific key exchange. When the receiving AS adds new delegation records to the chain, it signs them with its own signing key and sets as_id to its own identifier. Cross-domain key trust relationships may be established through key exchange agreements, published JWKS endpoints ([RFC8414]), or a shared trust framework. Failure to properly verify cross-domain AS signatures may allow forged delegation records to be accepted.¶
Claim Semantics Across Domains: Claims such as sub, scope, and policy identifiers may have different semantics across trust domains. Implementations MUST ensure that claim interpretation is consistent or explicitly mapped at each domain boundary, following the claims transcription guidance in [I-D.ietf-oauth-identity-chaining].¶
Revocation Propagation: When the root authorization or any intermediate delegation is revoked, all downstream delegated tokens SHOULD be invalidated. Within a single trust domain, the AS can directly revoke delegated tokens. Across trust domains, implementations SHOULD mitigate the risk of stale delegated tokens through one or more of the following approaches: issuing short-lived delegated tokens to minimize the revocation window, implementing back-channel revocation notifications between ASes (e.g., using Token Revocation [RFC7009] or a proprietary notification mechanism), or requiring Resource Servers in the downstream domain to perform token introspection ([RFC7662]) before accepting delegated tokens.¶
Lateral Movement: An attacker who compromises an agent in one trust domain may attempt to use the delegation chain to move laterally to other trust domains. Cross-domain delegation SHOULD be restricted by policy to only the trust domains explicitly authorized by the original user consent.¶

10.9. Delegation Revocation

Revocation of delegated authorization is a critical security operation. This section defines the revocation semantics for delegation chains.¶

Revocation Scopes:¶

Root revocation: When the original user revokes the root authorization (the token without a delegation_chain), all downstream delegated tokens derived from that root authorization MUST be considered invalid. Resource Servers validating a delegation chain MUST verify that the root authorization remains valid, either by checking the root token's status directly or by using token introspection ([RFC7662]) on the root token.¶
Intermediate hop revocation: When a delegating agent revokes a specific delegation hop (e.g., Agent A revokes its delegation to Agent B), all tokens derived from that delegation (including further downstream delegations such as Agent B to Agent C to Agent D) MUST be considered invalid. Resource Servers SHOULD verify that no delegation record in the chain has been revoked. Within a single trust domain, this can be achieved by introspecting the token associated with each hop. In cross-domain or high-throughput deployments, performing per-hop introspection may be impractical; in such cases, Resource Servers MAY rely on short token lifetimes combined with back-channel revocation notifications to limit the window during which a revoked delegation remains effective.¶
Delegatee token revocation: When a delegatee agent's own token is revoked, only that specific token is affected. The delegation chain record itself remains valid for audit purposes, but the delegatee can no longer use the delegated authorization.¶

Revocation Detection Mechanisms: Resource Servers and downstream Authorization Servers MUST implement at least one of the following mechanisms to detect delegation revocation:¶

Short-lived tokens: Issue delegated tokens with short expiration times (e.g., 5 to 15 minutes) to limit the window during which a revoked delegation remains effective;¶
Token introspection: Perform token introspection ([RFC7662]) on each token in the delegation chain before accepting the delegated authorization, confirming that no token has been revoked;¶
Back-channel revocation notifications: Subscribe to revocation events from upstream Authorization Servers using Token Revocation ([RFC7009]) or a proprietary notification mechanism, enabling proactive invalidation of downstream delegated tokens.¶