Delegation Chain for OAuth 2.0
draft-liu-oauth-chain-delegation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dapeng Liu , Judy Zhu , Suresh Krishnan , Aaron Parecki | ||
| Last updated | 2026-06-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-oauth-chain-delegation-00
Web Authorization Protocol D. Liu
Internet-Draft H. Zhu
Intended status: Standards Track Alibaba Group
Expires: 8 December 2026 S. Krishnan
Cisco
A. Parecki
Okta
6 June 2026
Delegation Chain for OAuth 2.0
draft-liu-oauth-chain-delegation-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 December 2026.
Liu, et al. Expires 8 December 2026 [Page 1]
Internet-Draft OAuth Delegation Chain June 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Relationship to Existing Mechanisms . . . . . . . . . . . . . 5
2.1. Relationship to the act Claim . . . . . . . . . . . . . . 5
2.2. Relationship to Identity Chaining . . . . . . . . . . . . 6
2.3. Relationship to Claims Transcription . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. The delegation_chain Claim . . . . . . . . . . . . . . . . . 8
4.1. Claim Definition . . . . . . . . . . . . . . . . . . . . 8
4.2. Structure . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Delegation Lifecycle . . . . . . . . . . . . . . . . . . 9
4.4. Field Definitions . . . . . . . . . . . . . . . . . . . . 10
4.5. Key Resolution for Agent Identifiers . . . . . . . . . . 13
4.6. Chain Ordering . . . . . . . . . . . . . . . . . . . . . 14
5. Delegation with User Interaction . . . . . . . . . . . . . . 14
5.1. Step 1-2: Initial Authorization . . . . . . . . . . . . . 16
5.2. Step 3: Delegation Request . . . . . . . . . . . . . . . 16
5.3. Step 4: User Interaction Required . . . . . . . . . . . . 17
5.4. Steps 5-7: User Review and Approval . . . . . . . . . . . 18
5.5. Step 8: Retry Token Exchange . . . . . . . . . . . . . . 18
5.6. Step 9: AS Validation . . . . . . . . . . . . . . . . . . 19
5.7. Step 10: Token Issuance . . . . . . . . . . . . . . . . . 19
5.8. Steps 11-12: API Request and Validation . . . . . . . . . 19
5.9. When to Require Interaction . . . . . . . . . . . . . . . 20
6. Delegation without User Interaction . . . . . . . . . . . . . 20
7. Chain Extension . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Evidence Propagation . . . . . . . . . . . . . . . . . . 22
7.2. For First Delegation . . . . . . . . . . . . . . . . . . 22
7.3. For Subsequent Delegations . . . . . . . . . . . . . . . 23
8. Cross-Domain Delegation . . . . . . . . . . . . . . . . . . . 24
8.1. Cross-Domain Delegation Flow . . . . . . . . . . . . . . 25
8.2. Cross-Domain Trust Requirements . . . . . . . . . . . . . 26
Liu, et al. Expires 8 December 2026 [Page 2]
Internet-Draft OAuth Delegation Chain June 2026
8.3. Multi-Domain Chain Extension . . . . . . . . . . . . . . 27
8.4. Claims Transcription for Delegation . . . . . . . . . . . 27
9. Resource Server Validation . . . . . . . . . . . . . . . . . 28
9.1. Signature Verification . . . . . . . . . . . . . . . . . 28
9.2. Root Authorization Anchor . . . . . . . . . . . . . . . . 28
9.3. Dual-Signature Verification . . . . . . . . . . . . . . . 29
9.4. Agent Identifier Status Validation . . . . . . . . . . . 29
9.5. Chain Continuity . . . . . . . . . . . . . . . . . . . . 30
9.6. Scope and Policy Validation . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 30
10.2. Privilege Escalation Prevention . . . . . . . . . . . . 32
10.3. Chain Integrity . . . . . . . . . . . . . . . . . . . . 32
10.4. Chain Stripping Prevention . . . . . . . . . . . . . . . 33
10.5. Token Protection . . . . . . . . . . . . . . . . . . . . 33
10.6. Delegation Depth Limits . . . . . . . . . . . . . . . . 35
10.7. Cross-Domain Trust . . . . . . . . . . . . . . . . . . . 36
10.8. Delegation Revocation . . . . . . . . . . . . . . . . . 37
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
11.1. Data Minimization . . . . . . . . . . . . . . . . . . . 38
11.2. Cross-Domain Information Leakage . . . . . . . . . . . . 39
11.3. User Consent Transparency . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
12.1. JWT Claims Registration . . . . . . . . . . . . . . . . 39
12.2. OAuth Parameters Registration . . . . . . . . . . . . . 40
12.3. OAuth Error Registration . . . . . . . . . . . . . . . . 40
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . 41
13.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Complete Multi-Hop Example . . . . . . . . . . . . . 43
Appendix B. Validation Checklist . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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
Liu, et al. Expires 8 December 2026 [Page 3]
Internet-Draft OAuth Delegation Chain June 2026
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.
Liu, et al. Expires 8 December 2026 [Page 4]
Internet-Draft OAuth Delegation Chain June 2026
*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.
*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.
Liu, et al. Expires 8 December 2026 [Page 5]
Internet-Draft OAuth Delegation Chain June 2026
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 (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.
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;
Liu, et al. Expires 8 December 2026 [Page 6]
Internet-Draft OAuth Delegation Chain June 2026
* *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 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.
3. Terminology
Delegator: An agent that transfers a subset of its authorization to
another agent.
Liu, et al. Expires 8 December 2026 [Page 7]
Internet-Draft OAuth Delegation Chain June 2026
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.
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:
Liu, et al. Expires 8 December 2026 [Page 8]
Internet-Draft OAuth Delegation Chain June 2026
{
"delegation_chain": [
{
"delegator_id": "wit://agent-a.example/sha256.aaa111...",
"delegatee_id": "wit://agent-b.example/sha256.bbb222...",
"delegation_timestamp": 1734516900,
"root_evidence_ref": "evidence-root-abc123",
"delegated_policy": {
"type": "rego",
"content": "package agent\ndefault allow = false\n\nallow {\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:
1. *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.
2. *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
[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.
Liu, et al. Expires 8 December 2026 [Page 9]
Internet-Draft OAuth Delegation Chain June 2026
3. *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]).
4. *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
+====================+===========+===========+=======================================+
|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). |
+--------------------+-----------+-----------+---------------------------------------+
Liu, et al. Expires 8 December 2026 [Page 10]
Internet-Draft OAuth Delegation Chain June 2026
|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 |
Liu, et al. Expires 8 December 2026 [Page 11]
Internet-Draft OAuth Delegation Chain June 2026
| | | |trust anchor and the deployment does |
| | | |not require independent delegator non- |
| | | |repudiation. |
+--------------------+-----------+-----------+---------------------------------------+
|as_signature |string |REQUIRED |AS signature over this delegation |
| | | |record. |
+--------------------+-----------+-----------+---------------------------------------+
Table 1: delegation_chain Record Fields
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]), 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).
Liu, et al. Expires 8 December 2026 [Page 12]
Internet-Draft OAuth Delegation Chain June 2026
* 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 the delegator_signature when present, MUST be
computed over the same set of fields using JSON Canonicalization
Scheme (JCS) as defined in [RFC8785]:
* 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
([RFC7515] 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.
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:
Liu, et al. Expires 8 December 2026 [Page 13]
Internet-Draft OAuth Delegation Chain June 2026
* *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. This flow extends the JWT
Authorization Grant Interaction Response
([I-D.parecki-oauth-jwt-grant-interaction-response]) to OAuth 2.0
Token Exchange requests ([RFC8693], 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.
+--------+ +---------+ +--------+ +---------+ +---------+
| User | | Agent A | | AS | | Agent B | | RS |
+--------+ +---------+ +--------+ +---------+ +---------+
| | | | |
| (1) Initial | | | |
| Authorization | | | |
| (OAuth flow) | | | |
|---------------> | | | |
Liu, et al. Expires 8 December 2026 [Page 14]
Internet-Draft OAuth Delegation Chain June 2026
| | | | |
| | (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 |
Liu, et al. Expires 8 December 2026 [Page 15]
Internet-Draft OAuth Delegation Chain June 2026
| | | |<----------------|
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%3Aaccess_token
&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.
Liu, et al. Expires 8 December 2026 [Page 16]
Internet-Draft OAuth Delegation Chain June 2026
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 [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 defined 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;
Liu, et al. Expires 8 December 2026 [Page 17]
Internet-Draft OAuth Delegation Chain June 2026
* interval: The minimum polling interval in seconds (default: 5);
* expires_in: The number of seconds until the interaction session
expires.
[I-D.parecki-oauth-jwt-grant-interaction-response] 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
([RFC8693], 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.
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.
Liu, et al. Expires 8 December 2026 [Page 18]
Internet-Draft OAuth Delegation Chain June 2026
5.6. Step 9: AS Validation
The AS MUST perform the following validations:
1. 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.
2. Token Validity: Verify Agent A's token is valid and not revoked.
3. Delegation Permission: Confirm the token permits delegation
(e.g., includes a delegation scope or flag).
4. Scope Subset: Verify the requested scope is a subset of Agent A's
authorized scope (equal to or narrower).
5. Delegatee Authentication: Validate Agent B's agent identifier
(delegatee_id) to confirm the delegatee is authentic and
currently active.
6. Chain Depth: Optionally enforce maximum delegation depth.
7. 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.
Liu, et al. Expires 8 December 2026 [Page 19]
Internet-Draft OAuth Delegation Chain June 2026
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.
6. Delegation without User Interaction
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 Section 5.9 apply, the AS
responds to the Token Exchange request with a success response
containing the delegated token, bypassing the interaction_required
step.
Liu, et al. Expires 8 December 2026 [Page 20]
Internet-Draft OAuth Delegation Chain June 2026
+--------+ +---------+ +--------+ +---------+ +---------+
| 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) Validate | |
| | | - Token A valid| |
| | | - Scope subset | |
| | | - Standing auth| |
| | | or pre-approved |
| | | | |
| | | (5) Issue Token B |
| | |--------------->| |
| | | with delegation_chain |
| | | | |
| | | | (6) API Request|
| | | |---------------->|
| | | | |
| | | | (7) Validate |
| | | | chain |
| | | |<----------------|
Figure 4
The Token Exchange request format, parameters, and validation rules
are identical to those defined in Section 5. 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;
Liu, et al. Expires 8 December 2026 [Page 21]
Internet-Draft OAuth Delegation Chain June 2026
* 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
[I-D.liu-oauth-authorization-evidence] 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.
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 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 Section 8.
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.
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:
Liu, et al. Expires 8 December 2026 [Page 22]
Internet-Draft OAuth Delegation Chain June 2026
{
"delegation_chain": [
{
"delegator_id": "wit://agent-a.example/sha256.aaa111...",
"delegatee_id": "wit://agent-b.example/sha256.bbb222...",
"delegation_timestamp": 1734516900,
"root_evidence_ref": "evidence-root-abc123",
"delegated_policy": {
"type": "rego",
"content": "package agent\ndefault allow = false\n\nallow {\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,
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:
Liu, et al. Expires 8 December 2026 [Page 23]
Internet-Draft OAuth Delegation Chain June 2026
{
"delegation_chain": [
{
"delegator_id": "wit://agent-b.example/sha256.bbb222...",
"delegatee_id": "wit://agent-c.example/sha256.ccc333...",
"delegation_timestamp": 1734517800,
"root_evidence_ref": "evidence-root-abc123",
"delegated_policy": {
"type": "rego",
"content": "package agent\ndefault allow = false\n\nallow {\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...",
"delegation_timestamp": 1734516900,
"root_evidence_ref": "evidence-root-abc123",
"delegated_policy": {
"type": "rego",
"content": "package agent\ndefault allow = false\n\nallow {\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].
Liu, et al. Expires 8 December 2026 [Page 24]
Internet-Draft OAuth Delegation Chain June 2026
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 signatur|
| | | | |- delegation |
| | | | |- policy |
| | | | | |
| | | | |(6) Access |
| | | | | Token |
| | | |<---------| |
| | | | | |
| | | |(7) API Req |
| | | |------------------------>|
| | | | | |
Figure 7
1. Agent A obtains initial authorization from the user in Trust
Domain A (root authorization, no delegation_chain).
Liu, et al. Expires 8 December 2026 [Page 25]
Internet-Draft OAuth Delegation Chain June 2026
2. 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]). This signals
that the delegation targets an agent in Trust Domain B.
3. 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.
4. 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].
5. AS-B validates the JWT grant signature, verifies the
delegation_chain (including AS-A's signature on each record), and
confirms policy narrowing constraints.
6. AS-B issues an access token to Agent B for Trust Domain B,
preserving the delegation_chain claim from the JWT authorization
grant.
7. 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 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
Liu, et al. Expires 8 December 2026 [Page 26]
Internet-Draft OAuth Delegation Chain June 2026
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 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.
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
Liu, et al. Expires 8 December 2026 [Page 27]
Internet-Draft OAuth Delegation Chain June 2026
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 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.
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 the as_signature on
each record attests to that verification.
Liu, et al. Expires 8 December 2026 [Page 28]
Internet-Draft OAuth Delegation Chain June 2026
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
[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, 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.
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:
Liu, et al. Expires 8 December 2026 [Page 29]
Internet-Draft OAuth Delegation Chain June 2026
* *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].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.
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
10.1. Threat Model
This section describes the threat model underlying the
delegation_chain mechanism and the security properties it provides.
Liu, et al. Expires 8 December 2026 [Page 30]
Internet-Draft OAuth Delegation Chain June 2026
*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:
Liu, et al. Expires 8 December 2026 [Page 31]
Internet-Draft OAuth Delegation Chain June 2026
* *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
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.
Liu, et al. Expires 8 December 2026 [Page 32]
Internet-Draft OAuth Delegation Chain June 2026
* *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.
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. 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.
Liu, et al. Expires 8 December 2026 [Page 33]
Internet-Draft OAuth Delegation Chain June 2026
* *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.8).
Liu, et al. Expires 8 December 2026 [Page 34]
Internet-Draft OAuth Delegation Chain June 2026
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.6. 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 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 ([RFC7662]) to
retrieve the delegation_chain on demand;
Liu, et al. Expires 8 December 2026 [Page 35]
Internet-Draft OAuth Delegation Chain June 2026
* *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.7. 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.
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 ([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
Liu, et al. Expires 8 December 2026 [Page 36]
Internet-Draft OAuth Delegation Chain June 2026
(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.8. 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 (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.
Liu, et al. Expires 8 December 2026 [Page 37]
Internet-Draft OAuth Delegation Chain June 2026
*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.
*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.
11. Privacy Considerations
In addition to the privacy considerations outlined in [RFC8693] and
[RFC7519], the following privacy considerations apply to the
delegation_chain mechanism defined in this specification.
11.1. Data Minimization
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.
Liu, et al. Expires 8 December 2026 [Page 38]
Internet-Draft OAuth Delegation Chain June 2026
* Agent identifiers (delegator_id, delegatee_id) should be
pseudonymous where possible, avoiding direct exposure of
personally identifiable information.
11.2. Cross-Domain Information Leakage
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
[I-D.ietf-oauth-identity-chaining].
* 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.
11.3. User Consent Transparency
When the Delegation Interaction Phase is triggered (as described in
Section 5), 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.
12. IANA Considerations
12.1. JWT Claims Registration
This specification registers the following claim in the "JSON Web
Token Claims" registry:
Liu, et al. Expires 8 December 2026 [Page 39]
Internet-Draft OAuth Delegation Chain June 2026
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: Section 4 of this document
12.2. OAuth Parameters Registration
This specification registers the following parameters in the "OAuth
Parameters" registry established by [RFC6749] Section 11.2:
Parameter Name: delegatee_id
Parameter Usage Location: token request
Change Controller: IETF
Reference: Section 5.2 of this document
The interaction_callback_uri parameter is used in the delegation
Token Exchange request context (Section 5.2) to receive a redirect
callback upon completion of user interaction. The parameter is
defined and registered by
[I-D.parecki-oauth-jwt-grant-interaction-response]; 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.
12.3. OAuth Error Registration
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 [RFC6749] 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.
Liu, et al. Expires 8 December 2026 [Page 40]
Internet-Draft OAuth Delegation Chain June 2026
policy_expansion_detected: The requested delegated_policy or scope
is broader than the delegator's authorized policy, violating the
policy narrowing constraint defined in Section 4.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/info/rfc7523>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
Liu, et al. Expires 8 December 2026 [Page 41]
Internet-Draft OAuth Delegation Chain June 2026
[I-D.ietf-oauth-identity-chaining]
Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins,
M. J., Campbell, B., and A. Parecki, "OAuth Identity and
Authorization Chaining Across Domains", Work in Progress,
Internet-Draft, draft-ietf-oauth-identity-chaining-14, 2
June 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-identity-chaining-14>.
[I-D.parecki-oauth-jwt-grant-interaction-response]
Parecki, A., Campbell, B., and D. Liu, "JWT Authorization
Grant Interaction Response", Work in Progress, Internet-
Draft, draft-parecki-oauth-jwt-grant-interaction-response-
00, 24 March 2026, <https://datatracker.ietf.org/doc/html/
draft-parecki-oauth-jwt-grant-interaction-response-00>.
13.2. Informative References
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[I-D.liu-oauth-rego-policy]
Liu, D., "Rego Policy Language for OAuth 2.0", Work in
Progress, Internet-Draft, draft-liu-oauth-rego-policy,
March 2026, <https://maxpassion.github.io/IETF-Agent-
Operation-Authorization-draft/draft-liu-oauth-rego-policy-
00.html>.
[I-D.ietf-oauth-identity-assertion-authz-grant]
Ying, K. and B. Campbell, "OAuth 2.0 Identity Assertion
Authorization Grant", Work in Progress, Internet-Draft,
draft-ietf-oauth-identity-assertion-authz-grant, January
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
oauth-identity-assertion-authz-grant>.
Liu, et al. Expires 8 December 2026 [Page 42]
Internet-Draft OAuth Delegation Chain June 2026
[I-D.liu-oauth-authorization-evidence]
Liu, D., "Authorization Evidence for OAuth 2.0", Work in
Progress, Internet-Draft, draft-liu-oauth-authorization-
evidence, March 2026, <https://maxpassion.github.io/IETF-
Agent-Operation-Authorization-draft/draft-liu-oauth-
authorization-evidence-00.html>.
Appendix A. Complete Multi-Hop Example
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:
{
"iss": "https://as.example.com",
"sub": "user_12345",
"aud": "https://api.shop.example",
"exp": 1734520500,
"iat": 1734517800,
"act": {
"sub": "wit://agent-c.example/sha256.ccc333..."
},
"delegation_chain": [
{
"delegator_id": "wit://agent-b.example/sha256.bbb222...",
"delegatee_id": "wit://agent-c.example/sha256.ccc333...",
"delegation_timestamp": 1734517800,
"root_evidence_ref": "evidence-root",
"delegated_policy": {
"type": "rego",
"content": "package agent\ndefault allow = false\n\nallow {\n input.action == \"inventory_check\"\n input.item_id == \"123\"\n}",
"entry_point": "allow"
},
"operation_summary": "Check stock for item 123",
"delegator_signature": "eyJhbGciOiJFUzI1NiJ9..MEYCIQD2...",
"as_signature": "eyJhbGciOiJSUzI1NiJ9..MEUCIQDy..."
},
{
"delegator_id": "wit://agent-a.example/sha256.aaa111...",
"delegatee_id": "wit://agent-b.example/sha256.bbb222...",
"delegation_timestamp": 1734516900,
"root_evidence_ref": "evidence-root",
"delegated_policy": {
"type": "rego",
"content": "package agent\ndefault allow = false\n\nallow {\n input.action == \"cart_op\"\n}\nallow {\n input.action == \"inventory_op\"\n}",
"entry_point": "allow"
},
Liu, et al. Expires 8 December 2026 [Page 43]
Internet-Draft OAuth Delegation Chain June 2026
"operation_summary": "Delegate inventory operations",
"delegator_signature": "eyJhbGciOiJFUzI1NiJ9..MEYCIQD1...",
"as_signature": "eyJhbGciOiJSUzI1NiJ9..MEUCIQDx..."
}
],
"evidence": {
"id": "evidence-root",
"user_confirmation": {
"displayed_content": "Allow shopping assistant to manage cart",
"user_action": "confirmed_via_button_click",
"timestamp": 1734516000,
"interface_version": "consent-ui-v2.1"
},
"session_context": {
"session_id": "session_xyz789",
"channel": "mobile-app"
},
"as_signature": "eyJhbGciOiJSUzI1NiJ9..MEUCIQDw..."
},
"audit_trail": {
"evidence_ref": "evidence-root",
"semantic_expansion_level": "medium",
"interpretation_notes": "User said 'manage cart', delegated to inventory operations"
}
}
Figure 8
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
Liu, et al. Expires 8 December 2026 [Page 44]
Internet-Draft OAuth Delegation Chain June 2026
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).
Appendix B. Validation Checklist
This appendix provides a condensed checklist for implementers. The
normative requirements are specified in Section 9 and Section 10;
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:*
1. Verify token-level JWT signature against iss
2. Verify as_signature on each delegation record
3. Verify delegator_signature when present (SHOULD)
4. Check chain continuity: record[i].delegator_id ==
record[i-1].delegatee_id
5. Check act.sub == record[0].delegatee_id
6. Check timestamp ordering (descending, within validity)
Liu, et al. Expires 8 December 2026 [Page 45]
Internet-Draft OAuth Delegation Chain June 2026
7. Check scope narrowing (MUST); check policy narrowing when
delegated_policy present (SHOULD)
8. Verify root authorization anchor (see Section 9)
9. 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.
Authors' Addresses
Dapeng Liu
Alibaba Group
Email: max.ldp@alibaba-inc.com
Hongru Zhu
Alibaba Group
Email: hongru.zhr@alibaba-inc.com
Suresh Krishnan
Cisco
Email: suresh.krishnan@gmail.com
Aaron Parecki
Okta
Email: aaron@parecki.com
Liu, et al. Expires 8 December 2026 [Page 46]