Delegation Chain for OAuth 2.0

Delegation Chain for OAuth 2.0 Alibaba Group

max.ldp@alibaba-inc.com

Alibaba Group

hongru.zhr@alibaba-inc.com

Cisco

suresh.krishnan@gmail.com

Okta

aaron@parecki.com

Security Web Authorization Protocol OAuth Delegation Chain Multi-hop Agent RFC 8693 defines the act claim for expressing delegation semantics in JWTs, including nested multi-hop actor identification. However, act captures only the identity of each actor in the chain, not the authorization constraints applied at each hop, and is constructed unilaterally by the Authorization Server without cryptographic confirmation from the delegating agent. This specification defines the delegation_chain JWT claim as a structured delegation record companion to act: an ordered array of delegation records, each capturing the Authorization Server's attestation and, when present, the delegated policy constraints, and optionally carrying the delegator's cryptographic confirmation. Together, act and delegation_chain provide both runtime authorization and verifiable delegation lineage for multi-hop agent delegation. The specification supports cross-domain delegation by composing with the identity chaining transport pattern, and integrates a user interaction mechanism for explicit consent when required by policy or regulation.

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. defines the cross-domain transport pattern combining Token Exchange () and JWT Authorization Grant () 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 () 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 () and 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. Deployment Options: A minimal deployment requires only the delegation_chain claim structure (), the delegation Token Exchange flow (), and the AS validation rules (). Implementations MAY additionally support structured policy (delegated_policy), user interaction (), cross-domain delegation (), delegator_signature, and authorization evidence propagation, depending on deployment requirements.

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.

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.

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 signed records. Each record captures the AS's attestation (as_signature), the policy constraints applied at that hop (scope, and — when present — delegated_policy), and — when present — 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 () 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.

defines a general-purpose pattern for preserving identity and authorization information across trust domains, combining Token Exchange () and JWT Authorization Grant (). 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 () 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.

Section 2.5 of 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 party (the AS via as_signature, and — when present — the delegator via delegator_signature). 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.

Delegator:: An agent that transfers a subset of its authorization to another agent.
Delegatee:: An agent that receives delegated authorization from a delegator.
Delegation Hop:: A single transfer of authorization from one agent to another.
Delegation Chain:: An ordered sequence of delegation hops from the most recent back to the original authorization.
Root Authorization:: The original authorization granted by a human principal, from which all delegations derive.
Workload Identity Token (WIT):: A token that cryptographically attests to the identity of a workload or agent, typically issued by a workload identity provider. A WIT URI is a URI that identifies a specific agent and references the WIT bound to that agent's identity.
Agent Identifier:: A URI used to identify a delegating or delegatee agent in a delegation record. This specification defines two URI schemes for agent identifiers: WIT URIs (wit://) and SPIFFE IDs (spiffe://). The identifier MUST be resolvable to a verifiable public key for signature verification when delegator_signature is present.

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

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:

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

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 (, 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 ) 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_signature	string	REQUIRED	AS signature over this delegation record.

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 ), ALFA (Attribute-based Logical Framework for Authorization), XACML, or any other policy representation agreed upon by the delegator and the Authorization Server.

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 preceding 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 ).

The as_signature, and the delegator_signature when present, MUST be computed over the same set of fields using JSON Canonicalization Scheme (JCS) as defined in :

delegator_id
delegatee_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 signatures MUST use detached JWS format ( Appendix F) with appropriate algorithm identifiers (e.g., RS256, ES256). 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 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.

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.

This section defines the delegation flow with explicit user interaction, used when the Authorization Server determines that user consent is required before delegation. This flow extends the JWT Authorization Grant Interaction Response () to OAuth 2.0 Token Exchange requests (, grant_type=token-exchange). 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.

| | | | | | | | | | | (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 | | | | | | | | | | (11) API Request| | | | |---------------->| | | | | | | | | | (12) Validate | | | | | chain | | | | |<----------------| ]]>

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

Agent A initiates delegation using OAuth 2.0 Token Exchange . 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:

This specification defines the following extension parameter for use with Token Exchange 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 ). 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:access_token. Implementations MAY request JWT format using urn:ietf:params:oauth:token-type:jwt.
resource (OPTIONAL): The identifier of the target Authorization Server when the delegation crosses a trust domain boundary, as defined in . 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 defined in . This parameter is used in conjunction with the interaction_required response to signal the client that user interaction has been completed.

When the Authorization Server determines that user interaction is required (see 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.

defines the interaction response mechanism for the JWT Authorization Grant (RFC 7523, grant_type=jwt-bearer). This specification extends that interaction response to apply to OAuth 2.0 Token Exchange requests (, grant_type=token-exchange) used for delegation. The same response semantics 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.

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.

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.

The AS MUST perform the following validations:

Interaction Completion (CONDITIONAL): When user interaction was required (see ), 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.
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.

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)

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 .

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.

In scenarios where user interaction is not required — for example, when the delegation is covered by a standing authorization or the policy has been pre-approved — the AS MAY skip the user interaction step and proceed directly with token issuance. This simplified flow reduces latency and user friction for routine delegation scenarios. When none of the conditions listed in apply, the AS responds to the Token Exchange request with a success response containing the delegated token, bypassing the interaction_required step.

| | | | | | | | | | | (2) Token A | | | | | (root, no | | | | | chain) | | | | |<----------------| | | | | | | | | | (3) Token Exchange (delegation) | | | |---------------->| | | | | - subject_token | | | | - delegatee_id | | | | - authorization_details | | | | | | | | | | (4) Validate | | | | | - Token A valid| | | | | - Scope subset | | | | | - Standing auth| | | | | or pre-approved | | | | | | | | | (5) Issue Token B | | | |--------------->| | | | | with delegation_chain | | | | | | | | | | (6) API Request| | | | |---------------->| | | | | | | | | | (7) Validate | | | | | chain | | | | |<----------------| ]]> The Token Exchange request format, parameters, and validation rules are identical to those defined in . The only difference is that the AS does not require user interaction before issuing the delegated token. This simplified flow is appropriate when:

The delegation is covered by a standing authorization previously granted by the user;
The delegated policy is equal to or more restrictive than a previously user-approved policy;
The delegation does not cross trust domain boundaries;
The delegation does not involve high-risk operations;
No regulatory requirements mandate explicit user consent.

Authorization Servers SHOULD log all decisions to skip user interaction as part of their audit trail. Implementations using structured authorization evidence (as described in or a deployment-specific model) SHOULD record the skip decision in the audit_trail claim; other deployments MAY record it in an application-specific audit log.

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

When the AS issues a delegated token within the same trust domain and structured authorization evidence is used, it SHOULD propagate the evidence and audit_trail claims 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 . Implementations not using structured authorization evidence are not required to carry evidence or audit_trail 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.

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:

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

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

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.

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 .

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

| | | | | | | | | | | | | (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 signatur| | | | | |- delegation | | | | | |- policy | | | | | | | | | | | |(6) Access | | | | | | Token | | | | |<---------| | | | | | | | | | | |(7) API Req | | | | |------------------------>| | | | | | | ]]>

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 ). 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 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 (), as defined in .
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.

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 ().
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 and audit_trail claims 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.

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 that issued that record (which may differ across records);
Verify trust relationships between all ASes referenced in the chain;
Verify chain continuity and policy narrowing across domain boundaries.

Section 2.5 of 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.

Resource Servers validate the delegation_chain as follows:

For each record in the chain, verify the as_signature using the AS's public key. This ensures:

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

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 () 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 the as_signature on each record attests to that verification.

In deployments using structured authorization evidence, the Resource Server SHOULD additionally verify that the root token contains valid evidence and audit_trail claims (as described in 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.

For each delegation record, the Resource Server MUST verify the as_signature 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).

AS Signature (MUST): 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.

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.

Verify the chain is continuous:

For each record at index i (where i > 0), record[i].delegator_id MUST equal record[i-1].delegatee_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.

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.

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.

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.

The as_signature on each record, together with the token-level JWT signature, ensures chain integrity through the following mechanisms:

Forgery prevention: Agents cannot forge delegation records because the as_signature requires the AS's private signing key, which agents do not possess.
Tamper detection: Agents cannot modify existing records because any change to the signed fields (including delegator_id, delegatee_id, scope, and delegated_policy) invalidates both the record-level as_signature and the token-level JWT signature.
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.

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.

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 () to retrieve the authoritative delegation_chain from the AS, rather than trusting any client-supplied chain data.

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

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.

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 invalid_grant 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 detached 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 () 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.

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. To determine which AS signed each record, implementations SHOULD use the token's iss claim to identify the AS that issued the current token: during Claims Transcription at a domain boundary, the receiving AS re-signs the upstream delegation records, so the as_signature on all records in the chain can be verified using the issuing AS's signing key. Alternatively, deployments MAY establish a mapping from agent identifier domains to AS domains through deployment-specific configuration. Cross-domain key trust relationships may be established through key exchange agreements, published JWKS endpoints (), 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 .
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 or a proprietary notification mechanism), or requiring Resource Servers in the downstream domain to perform token introspection () 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.

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 () 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 (Agent B → Agent C → 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 () 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 () or a proprietary notification mechanism, enabling proactive invalidation of downstream delegated tokens.

Audit Trail Preservation: Revocation does not retroactively modify existing tokens. Delegation records remain in previously issued tokens for audit trail reconstruction purposes. Resource Servers MUST reject tokens containing revoked delegation hops (as detected through the mechanisms above), but the historical record of the delegation is preserved for forensic analysis.

In addition to the privacy considerations outlined in and , the following privacy considerations apply to the delegation_chain mechanism defined in this specification.

The delegation_chain claim carries identity and authorization information about the original user, all intermediate agents, and the delegation policies. As the chain grows with each hop, the amount of information embedded in the token increases. Implementations should apply data minimization principles:

The operation_summary field is OPTIONAL and should contain only the minimum information necessary for authorization decisions, not detailed descriptions of user intent or behavior.
The delegated_policy should be scoped to the specific operations being delegated, not include broader context about the user's overall authorization.
Agent identifiers (delegator_id, delegatee_id) should be pseudonymous where possible, avoiding direct exposure of personally identifiable information.

When delegation chains cross trust domain boundaries, the delegation_chain claim propagates user and agent identity information from the originating domain to downstream domains. This creates the following privacy risks:

The sub claim reveals the original user's identity in the originating domain to all downstream domains. Implementations should consider identifier mapping or pairwise pseudonymous identifiers, following the claims transcription guidance in .
The evidence claim may contain details about the user's consent interaction (e.g., displayed content, session context, channel). Downstream domains receive this information. ASes should minimize the evidence payload or apply domain-specific filtering before cross-domain propagation.
The complete delegation chain reveals the full topology of agent relationships, which may be sensitive in competitive or multi-tenant environments.

When the Delegation Interaction Phase is triggered (as described in ), the user is presented with delegation details for review and approval. Implementations should ensure that the consent UI clearly communicates:

The identity of the delegatee agent receiving the delegation;
The specific operations being delegated;
Whether the delegation crosses trust domain boundaries;
The user's ability to revoke the delegation at any time.

This specification registers the following claim in the "JSON Web Token Claims" registry:

Claim Name:: delegation_chain
Claim Description:: An ordered array of AS-signed delegation records tracing agent-to-agent authorization transfers, enabling end-to-end validation of delegation lineage.
Change Controller:: IETF
Specification Document:: of this document

This specification registers the following parameters in the "OAuth Parameters" registry established by Section 11.2:

Parameter Name:: delegatee_id
Parameter Usage Location:: token request
Change Controller:: IETF
Reference:: of this document

The interaction_callback_uri parameter is used in the delegation Token Exchange request context () to receive a redirect callback upon completion of user interaction. The parameter is defined and registered by ; this specification extends its usage from the JWT Authorization Grant (grant_type=jwt-bearer) to the Token Exchange grant type (grant_type=token-exchange). No additional IANA registration is required.

This specification defines the following error codes for use in delegation Token Exchange responses. These errors extend the OAuth 2.0 error registry established by Section 11.4:

invalid_delegation_chain:: The delegation_chain claim in the presented token fails validation (e.g., broken chain continuity, invalid signatures, or expired timestamps). The AS MUST reject the delegation request.

delegation_depth_exceeded:: The delegation chain has reached the maximum number of hops permitted by the AS policy, and the requested delegation would exceed this limit.

policy_expansion_detected:: The requested delegated_policy or scope is broader than the delegator's authorized policy, violating the policy narrowing constraint defined in .

References Normative References Informative References Rego Policy Language for OAuth 2.0 OAuth 2.0 Identity Assertion Authorization Grant Authorization Evidence for OAuth 2.0

The following shows an extended token held by Agent C after two delegation hops (User → Agent A → Agent B → Agent C), using WIT-based identifiers, structured policies, and authorization evidence:

This token shows:

Original user: user_12345
Current actor: Agent C
Delegation path: Agent A → Agent B → Agent C
Progressive policy narrowing: cart+inventory → inventory → item:123
Original user consent evidence preserved

A scope-based equivalent of the same scenario would omit the delegated_policy, delegator_signature, root_evidence_ref, evidence, and audit_trail fields. Each delegation record would carry only delegator_id, delegatee_id, delegation_timestamp, operation_summary, and as_signature. The token's scope claim alone would express the progressively narrowing authorization (e.g., cart:read inventory:read → inventory:read → inventory:read:item:123).

This appendix provides a condensed checklist for implementers. The normative requirements are specified in and ; this checklist is informative only. Each delegation hop is represented as a separate JWT access token issued and signed by the Authorization Server. The delegating agent MAY additionally provide a delegator_signature within the delegation_chain record for dual-signature non-repudiation (RECOMMENDED). Token structure (per hop):

iss — Authorization Server identifier
sub — original user (preserved from root)
act.sub — delegatee agent identifier
delegation_chain — accumulated delegation records
Token signed by AS private key

Resource Server validation steps:

Verify token-level JWT signature against iss
Verify as_signature on each delegation record
Verify delegator_signature when present (SHOULD)
Check chain continuity: record[i].delegator_id == record[i-1].delegatee_id
Check act.sub == record[0].delegatee_id
Check timestamp ordering (descending, within validity)
Check scope narrowing (MUST); check policy narrowing when delegated_policy present (SHOULD)
Verify root authorization anchor (see Section )
Check agent identifier status (revocation / expiration)

Per-hop signing benefits: independent non-repudiation per delegator, flexible per-hop revocation, incremental chain updates, and discrete audit events.