Web Authorization Protocol D. Liu Internet-Draft Alibaba Intended status: Standards Track 2 November 2026 Expires: 6 May 2027 Delegation Chaining for the Identity Assertion JWT Authorization Grant draft-liu-oauth-delegation-chaining-00 Abstract The Identity Assertion JWT Authorization Grant (ID-JAG) defines how a client obtains a delegated authorization grant from an identity assertion. It leaves the validation of the actor_token, the related policy evaluation, and the act claim of the issued ID-JAG open for future profiles. This document defines those rules for delegation chains, in which a series of workloads, such as AI agents, act on behalf of an initial end-user across multiple hops. Each delegating workload authenticates to the Authorization Server and presents the ID-JAG it holds as the subject_token of an OAuth 2.0 Token Exchange request, together with the SPIFFE JWT-SVID of the workload it delegates to as the actor_token. The Authorization Server validates both workload identities, checks that the delegating workload matches the may_act claim of the subject_token, and enforces monotonic scope attenuation. It then issues a new ID-JAG for the next hop, carrying the actor chain in the act claim. The last workload of the chain delegates to no one and instead redeems its ID- JAG for an Access Token with the JWT bearer grant of [RFC7523]. An optional variant based on self-issued Delegation Assertions is defined for hops where the Authorization Server is not reachable. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://maxpassion.github.io/delegation-chaining-for-id-jag/draft- liu-oauth-delegation-chaining.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-liu- oauth-delegation-chaining/. Discussion of this document takes place on the Web Authorization Protocol Individual Draft mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Liu Expires 6 May 2027 [Page 1] Internet-Draft Delegation Chaining for ID-JAG November 2026 Source for this draft and an issue tracker can be found at https://github.com/maxpassion/delegation-chaining-for-id-jag. 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 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Workload Identity of the Actor . . . . . . . . . . . . . . . 6 4. Delegation Chaining . . . . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. The Delegation Request . . . . . . . . . . . . . . . . . 9 4.3. Redemption at the Last Hop . . . . . . . . . . . . . . . 11 4.4. Authorization Server Processing Requirements . . . . . . 12 4.5. The Issued ID-JAG . . . . . . . . . . . . . . . . . . . . 15 5. Optional Variant: Self-Issued Delegation Assertions . . . . . 17 5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Assertion Format . . . . . . . . . . . . . . . . . . . . 18 Liu Expires 6 May 2027 [Page 2] Internet-Draft Delegation Chaining for ID-JAG November 2026 5.3. Re-Issuance Rules . . . . . . . . . . . . . . . . . . . . 19 5.4. Redemption at the Authorization Server . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.1. Audience and Hop Binding . . . . . . . . . . . . . . . . 22 6.2. Transfer of the Target Entity's JWT-SVID . . . . . . . . 23 6.3. Monotonic Attenuation . . . . . . . . . . . . . . . . . . 24 6.4. Replay Prevention . . . . . . . . . . . . . . . . . . . . 24 6.5. Transport and Confidentiality . . . . . . . . . . . . . . 24 6.6. Workload Identity Compromise . . . . . . . . . . . . . . 24 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. Complete End-to-End Use Case: Multi-Hop Financial Research Agent Workflow . . . . . . . . . . . . . . . . . 28 A.1. Scenario Overview . . . . . . . . . . . . . . . . . . . . 28 A.2. Step-by-Step Protocol Flow . . . . . . . . . . . . . . . 28 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction and Problem Statement In modern distributed multi-tier application architectures and autonomous AI agent ecosystems (e.g., User -> Agent A -> Agent B -> Agent C -> MCP Tool), service-to-service execution chains frequently cross trust boundaries while operating on behalf of an initial end- user. The OAuth 2.0 framework [RFC6749] and the Identity Assertion JWT Authorization Grant (ID-JAG) [I-D.ietf-oauth-identity-assertion-authz-grant] address identity assertions and authorization grants for single-hop scenarios. However, two gaps remain in multi-hop execution chains: 1. The actor_token validation gap. Section 4.3 of [I-D.ietf-oauth-identity-assertion-authz-grant] states: "This specification does not define normative processing requirements for actor_token or whether an act claim is included in the issued ID-JAG. Future profiles or extensions MAY define how actor_token is validated, how it influences policy evaluation, and whether it results in an act claim in the issued ID-JAG." 2. The delegation continuation gap. A standardized mechanism is needed that lets an intermediate delegate, e.g., Agent B, propagate the end-user's authorization further down the chain, e.g., to Agent C, with strictly narrowed privileges, while Liu Expires 6 May 2027 [Page 3] Internet-Draft Delegation Chaining for ID-JAG November 2026 keeping every hop verifiable by the Authorization Server that issues the credential for it. This does not require a single trust root common to the whole chain. Each hop is validated by the AS named in the aud claim of the credential presented at that hop, and where consecutive hops fall in different trust domains, the two Authorization Servers rely on the inter-domain trust relationship described in Section 4.1. This document is such a profile. It defines how actor_token is validated, how it influences policy evaluation, and how the act claim is populated when ID-JAGs are chained across multiple hops. The mechanism combines: 1. SPIFFE workload identities, carried as JWT-SVIDs, as the machine identity of each actor [SPIFFE-ID] [SPIFFE-JWT-SVID]. 2. OAuth 2.0 Token Exchange [RFC8693] as the point where the machine identities of the delegating and the delegated workload and the delegated authorization of the end-user are verified and merged by the Authorization Server (AS). 3. The may_act claim (Section 4.4 of [RFC8693]) to bind each issued ID-JAG to the entity entitled to redeem it at the next hop, and the act claim (Section 4.1 of [RFC8693]) to carry the delegation lineage. Every hop of the chain performs exactly one request to an Authorization Server. Each ID-JAG in the chain is issued by an AS rather than minted by the delegating entity, so privilege attenuation is enforced at every hop rather than merely asserted by the entity that delegates, and the full lineage, e.g., User -> Agent A -> Agent B -> Agent C, is carried in the act claim of the final Access Token. This document is a profile of [I-D.ietf-oauth-identity-assertion-authz-grant], which is itself a profile of [I-D.ietf-oauth-identity-chaining]. Identity chaining combines OAuth 2.0 Token Exchange with the JWT bearer grant of [RFC7523] to carry one authorization across the boundary between two trust domains, and it intentionally leaves many details unspecified. This document supplies some of those details for a different shape of problem: a chain of more than two workloads in which each hop delegates to the next, where a hop may or may not cross a trust domain boundary. A hop that delegates onward uses an OAuth 2.0 Token Exchange request, defined in Section 4.2. The last hop of the chain delegates to no one; it redeems the ID-JAG it holds for an Access Token using the JWT bearer grant of [RFC7523], as Section 2 of [I-D.ietf-oauth-identity-chaining] requires. That form is defined in Section 4.3, and Section 4.4 states the checks that apply to both. Liu Expires 6 May 2027 [Page 4] Internet-Draft Delegation Chaining for ID-JAG November 2026 For hops where a round trip to the AS is not practical, for example across trust domains with no reachable common AS, this document also defines an optional variant based on self-issued Delegation Assertions, see Section 5. That variant offers weaker guarantees and supplements, but does not replace, the mechanism of Section 4. 2. Terminology This document uses the terms "authorization server" (AS), "client", "resource server" (RS), and "access token" defined in [RFC6749], the Token Exchange parameters defined in Section 2.1 of [RFC8693], the JWT bearer grant parameters defined in Section 2.1 of [RFC7523], and the act and may_act claims defined in Section 4.1 of [RFC8693] and Section 4.4 of [RFC8693]. In addition, this document defines the following roles and credentials: ID-JAG: An Identity Assertion JWT Authorization Grant [I-D.ietf-oauth-identity-assertion-authz-grant]. In this profile, an ID-JAG represents the delegated authorization of the end-user held by one entity of the chain. Delegating Entity (e.g., Agent A / Service A): An upstream workload that holds an ID-JAG and delegates a sub-operation or task to a downstream entity. Target Entity (e.g., Agent B / Service B): A downstream workload that receives the delegated authorization, executes computations, or further delegates to subsequent entities. Workload Identity (SPIFFE SVID): A machine identity credential issued to each workload instance by trusted infrastructure, such as SPIRE, serving as the immutable actor proof [SPIFFE-ID] [SPIFFE-JWT-SVID]. Delegation Assertion (DA): A short-lived JWT self-issued by a delegating entity in the optional variant of Section 5, carrying the initial user context, the delegation history, and privilege attenuation limits. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Liu Expires 6 May 2027 [Page 5] Internet-Draft Delegation Chaining for ID-JAG November 2026 3. Workload Identity of the Actor Every workload in the chain, for example an AI agent runtime or a container hosting an agentic loop, is provisioned with a cryptographic machine identity by trusted infrastructure, such as a SPIRE server. The identity is a SPIFFE ID [SPIFFE-ID]. SPIRE's Kubernetes workload registrar assigns IDs of the form: spiffe:///ns//sa/ The workload proves this identity with a JWT-SVID, a JWT whose sub claim carries the SPIFFE ID and which is signed by the SPIRE server of the trust domain. Verifying a JWT-SVID requires the SPIFFE trust bundle of that trust domain, whose JWT authorities are published as a JWK Set [RFC7517]. JWT-SVIDs are short-lived by design [SPIFFE-JWT-SVID]. SPIFFE defines a second credential form for the same identity, the X.509-SVID [SPIFFE-X509-SVID], which is a certificate for a key pair that the workload itself holds. The difference between the two forms matters for this document. A JWT-SVID is signed by the SPIRE server, so the workload carries it but cannot produce new signed material with it. An X.509-SVID gives the workload a private key it can sign with. The primary mechanism presents a JWT-SVID as the actor_token. The self-issued variant of Section 5 signs its Delegation Assertions with the X.509-SVID private key. In this profile, the JWT-SVID of the target entity is presented as the actor_token of the Token Exchange request described in Section 4.2. This binds the machine identity of the party that will wield the issued ID-JAG into the delegation chain, independently of any application-level identity. The delegating entity is identified separately, by authenticating at the token endpoint as the OAuth client. Its JWT-SVID MAY serve as the client authentication credential, as described in [I-D.ietf-oauth-spiffe-client-auth]. When SVID-based client authentication is not used, the AS MUST still authenticate the client with some other mechanism, because the act claim of the issued ID-JAG is built from the authenticated client identity rather than from the actor_token, see Section 4.4 and Section 4.5. 4. Delegation Chaining Liu Expires 6 May 2027 [Page 6] Internet-Draft Delegation Chaining for ID-JAG November 2026 4.1. Overview The chain starts like any ID-JAG flow. The end-user authenticates to the AS, for example with OpenID Connect [OpenID.Core]. The first workload, Agent A, requests its initial ID-JAG with the ID-JAG grant [I-D.ietf-oauth-identity-assertion-authz-grant], presenting the end- user's identity assertion. The initial ID-JAG has the end-user as its subject and carries the end-user's authorization for Agent A. When Agent A decides to delegate a sub-operation to Agent B, it does not mint the delegated credential itself. Agent A authenticates to the AS and sends a Token Exchange request to its token endpoint: subject_token is the ID-JAG Agent A holds, actor_token is Agent B's JWT-SVID, and audience names the AS that will redeem the new ID-JAG. The AS validates the request as described in Section 4.4 and issues a new ID-JAG. The subject remains the end-user, the act claim records Agent A as the current actor, and the may_act claim names Agent B as the entity entitled to redeem the new ID-JAG. Agent A passes the new ID-JAG to Agent B over the inter-agent transport, for example an HTTP header, gRPC metadata, or an MCP payload. Agent B now holds the delegated authorization and can either redeem it for an Access Token of a resource server or delegate further to Agent C in exactly the same way. Each hop of the chain therefore performs exactly one request to an AS, and every ID-JAG is issued by an AS that has validated the ID-JAG presented at the hop before it. Liu Expires 6 May 2027 [Page 7] Internet-Draft Delegation Chaining for ID-JAG November 2026 Agent A Agent B AS | | | |--(1) request JWT-SVID ->| | | with aud = the AS | | |<-(2) JWT-SVID of B -----| | | | | |--(3) Token Exchange ------------------------------------>| | subject_token = ID-JAG held by Agent A | | actor_token = JWT-SVID of Agent B | | | (4) authenticate A, | | | validate B, | | | check may_act, | | | attenuate | |<-(5) new ID-JAG -----------------------------------------| | act = A, may_act = B, client_id = B | | | | |--(6) pass new ID-JAG -->| | | over the A2A transport | | | | | | (7) Agent B now repeats | | | (3)-(6) to delegate | | | further, or redeems | | | the ID-JAG for an | | | Access Token | Figure 1: One hop of the delegation chain Figure 1 shows a single hop. The chain ends when the last workload redeems the ID-JAG it holds for an Access Token of the resource server it needs to call. The Access Token carries the complete actor chain in its act claim, e.g., User -> Agent A -> Agent B -> Agent C, which gives the resource server verifiable multi-hop provenance. When the target entity operates in a different trust domain with its own AS, the AS of the delegating entity issues the ID-JAG with the aud claim set to the issuer identifier of the target domain's AS, as described in [I-D.ietf-oauth-identity-assertion-authz-grant]. The target entity redeems the ID-JAG there. The processing requirements of Section 4.4 apply at whichever AS redeems the ID-JAG. The redeeming AS validates the signature of the ID-JAG against the signing key of the issuing AS identified by its iss claim, which it obtains through the inter-domain trust relationship between the two Authorization Servers. Liu Expires 6 May 2027 [Page 8] Internet-Draft Delegation Chaining for ID-JAG November 2026 4.2. The Delegation Request Every hop of the chain makes exactly one request to the token endpoint of an Authorization Server. A hop that delegates onward, that is, every hop but the last, sends an OAuth 2.0 Token Exchange request as defined in Section 2.1 of [RFC8693], with the following parameters: grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=(the ID-JAG held by the delegating entity) subject_token_type=urn:ietf:params:oauth:token-type:id-jag actor_token=(the JWT-SVID of the target entity) actor_token_type=urn:ietf:params:oauth:token-type:jwt requested_token_type=urn:ietf:params:oauth:token-type:id-jag audience=(the entity at which the issued token will be presented) resource=(the resource server the authorization is destined for) scope=(no wider than the scope of the subject_token) authorization_details=(no broader than those of the subject_token) The subject_token, subject_token_type, actor_token, actor_token_type, requested_token_type, and audience parameters are REQUIRED in this profile, notwithstanding that Section 2.1 of [RFC8693] defines actor_token and audience as OPTIONAL. The value of requested_token_type is always urn:ietf:params:oauth:token-type:id- jag in this request, because a hop that delegates onward always asks for an ID-JAG; the last hop sends a different request, see Section 4.3. The processing rules of Section 4.4 depend on the identity carried by the actor_token and derive the aud claim of the issued ID-JAG from audience. Client authentication is likewise mandatory, see Section 4.4. The resource parameter remains OPTIONAL as in [RFC8707] and is constrained by step 5 of Section 4.4 when present. Using the value urn:ietf:params:oauth:token-type:id-jag for subject_token_type is an extension of [I-D.ietf-oauth-identity-assertion-authz-grant], whose Section 4.3 lists only the id_token, saml2, and refresh_token values for that parameter. The URN itself is already registered by Section 10.2 of that document as a token type URI, which Section 3 of [RFC8693] permits in both subject_token_type and requested_token_type. It is this use of an ID-JAG as the subject_token of a further exchange that carries the delegation continuation gap of Section 1. Liu Expires 6 May 2027 [Page 9] Internet-Draft Delegation Chaining for ID-JAG November 2026 The scope and authorization_details [RFC9396] parameters together express the privileges requested for the next hop. Both MUST be no broader than the corresponding values of the subject_token, as the attenuation check of Section 4.4 requires. The authorization_details parameter carries the fine-grained narrowing, for example restricting access to a single resource, and is encoded as specified in [RFC9396]. The audience parameter has a single meaning throughout this profile: it names the entity at which the issued token will be presented, as Section 2.1 of [RFC8693] defines it. The token issued by this request is always an ID-JAG and is always redeemed at the AS of the next hop, so audience always names an Authorization Server and never a resource server, and the AS sets the aud claim of the issued ID-JAG to that identifier. Permitting audience to name an AS in the same trust domain as the requesting client is an extension of [I-D.ietf-oauth-identity-assertion-authz-grant], whose Section 4.3 defines audience as the Resource Authorization Server in another trust domain; the cross-domain case described there is one instance of the rule here. The identity of the target entity is carried in the actor_token instead, and the AS records it in the may_act claim of the issued ID-JAG, which binds the ID-JAG to the entity entitled to redeem it in the next request. The resource server for which the authorization is ultimately destined is named by the resource parameter [RFC8707], which is carried forward at every hop and which the last hop uses to set the aud claim of the Access Token it obtains, see Section 4.3. The actor_token identifies the party that will wield the issued ID- JAG, which is the reading Section 2.1 of [RFC8693] gives that parameter. The delegating entity is not named by any request parameter. It is identified by the client authentication it performs at the token endpoint, which SHOULD use its JWT-SVID as described in [I-D.ietf-oauth-spiffe-client-auth]. Other client authentication methods MAY be used. Client authentication is not optional in this profile, because the AS derives the act claim of the issued ID-JAG from the authenticated client identity, see Section 4.4 and Section 4.5. The delegating entity therefore has to obtain the JWT-SVID of its target from that target before it can make the request. The consequences of that transfer are discussed in Section 6.2. The response follows Section 2.2.1 of [RFC8693]. The issued ID-JAG is returned in the access_token parameter and token_type is set to N_A. Liu Expires 6 May 2027 [Page 10] Internet-Draft Delegation Chaining for ID-JAG November 2026 4.3. Redemption at the Last Hop The last workload of the chain delegates to no one. It redeems the ID-JAG it holds for an Access Token, and it does so with the JWT bearer grant of [RFC7523], as Section 2 of [I-D.ietf-oauth-identity-chaining] requires and as Section 4.4 of [I-D.ietf-oauth-identity-assertion-authz-grant] describes: grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer assertion=(the ID-JAG held by the redeeming entity) scope=(no wider than the scope of the assertion) This request, as defined here, uses the parameter values and encodings of Section 2.1 of [RFC7523] and takes no actor_token, no audience, and no resource parameter. The redeeming entity is identified by the client authentication it performs, which MUST succeed and which the AS MUST match against the may_act claim of the assertion, as step 4 of Section 4.4 requires. The aud claim of the assertion already names this AS, because that is what the audience parameter of the hop that issued it asked for, and Section 2.4.2 of [I-D.ietf-oauth-identity-chaining] permits that value to be either the token endpoint of the AS or its issuer identifier. The resource server for which access is requested is named by the resource claim of the assertion where that claim is present, carried forward from the hop that set it, and the AS sets the aud claim of the issued Access Token accordingly. Where the assertion carries no resource claim, the AS determines the audience of the Access Token by its own policy. Because the request carries no actor_token, the last hop presents no JWT-SVID at all, not even one of its own. The scope parameter MUST be no wider than the scope of the assertion, and since the request defined here carries no authorization_details or resource parameter, the fine-grained narrowing and the resource binding of the issued Access Token are those the assertion already carries. The AS MAY narrow them further by policy and MUST NOT widen them. The response is the access token response of Section 5.1 of [RFC6749], and an assertion that fails validation yields the invalid_grant error of Section 3.1 of [RFC7523]. Section 3.1 of [RFC7523] leaves client authentication to the policy of the Authorization Server; this profile requires it, because the act claim of the issued Access Token is built from the authenticated client identity, see Section 4.5. Liu Expires 6 May 2027 [Page 11] Internet-Draft Delegation Chaining for ID-JAG November 2026 4.4. Authorization Server Processing Requirements Upon receiving a request of either form, the delegation request of Section 4.2 or the last-hop request of Section 4.3, the AS executes the following verification and policy evaluation pipeline. These requirements answer the questions that Section 4.3 of [I-D.ietf-oauth-identity-assertion-authz-grant] leaves open, and they apply at every hop of the chain. Where a step names the subject_token, that is the assertion parameter at the last hop, and the same validation applies to it: 1. Client authentication: The AS MUST authenticate the client making the request. SVID-based client authentication [I-D.ietf-oauth-spiffe-client-auth] SHOULD be used, in which case the authenticated client is identified by its SPIFFE ID. The authenticated client is the delegating entity of this hop, and the AS MUST record it in the act claim of the issued token, see Section 4.5. A request that carries no client authentication MUST be rejected, because without it the AS cannot determine the actor of this hop. 2. Actor validation: Where the request carries an actor_token, the following applies. The last-hop request of Section 4.3 carries none and skips this step. The actor_token MUST be a JWT-SVID [SPIFFE-JWT-SVID]. The AS MUST verify its signature against the SPIFFE trust bundle of the actor's trust domain, MUST verify its temporal validity (exp and nbf), and MUST verify that it is an intended audience of the JWT-SVID as identified by its aud claim. If the AS holds no trust bundle for the trust domain of the actor, it MUST reject the request rather than skip this validation. The SPIFFE ID in the sub claim of the actor_token identifies the target entity of this hop. Where requested_token_type is urn:ietf:params:oauth:token-type:id-jag, as it is in every request of Section 4.2, the target entity is a downstream delegate and MUST differ from the authenticated client; the AS MUST reject a request in which the two are the same, because a hop that delegates to itself delegates to no one. Where requested_token_type is urn:ietf:params:oauth:token- type:access_token, as it is in the variant of Section 5.4, the requester is also the party that will wield the issued token and the two MUST be the same; the AS MUST reject a request in which they differ. 3. Subject validation: The subject_token MUST be validated as an ID- JAG as required by [I-D.ietf-oauth-identity-assertion-authz-grant], including signature, issuer, audience, expiration, not-before, and jti. The aud claim of the subject_token MUST identify the AS itself. Liu Expires 6 May 2027 [Page 12] Internet-Draft Delegation Chaining for ID-JAG November 2026 Where the subject_token carries a client_id claim, that claim MUST identify the authenticated client, as Section 4.4.1 of [I-D.ietf-oauth-identity-assertion-authz-grant] requires, and a request in which the two differ MUST be rejected. The AS MUST verify the signature of the subject_token against the signing key of the issuer identified by its iss claim. Where that issuer is the AS itself, this is its own key; where the subject_token was issued by an AS in another trust domain, see Section 4.1, the AS obtains that key through the inter-domain trust relationship. Because the issuing AS signs the ID-JAG, that signature covers the act chain the ID-JAG carries. 4. Hop binding: If the subject_token contains a may_act claim, the AS MUST verify that the sub member of may_act identifies the authenticated client, and MUST reject the request otherwise. This binds every ID-JAG to the single entity entitled to present it, so a stolen ID-JAG cannot be used by a different workload, and the delegating entity itself cannot redeem the ID-JAG it requested for its target. Note that may_act is compared against the authenticated client and not against the actor_token, because the actor_token names the entity of the next hop rather than the entity presenting this one. If the subject_token contains no may_act claim, as is the case for the initial ID-JAG obtained through the ID-JAG grant, the AS MUST apply its own policy to decide whether the authenticated client may delegate the subject_token further. In the request of Section 4.3, which carries no actor_token, this check is the only one that identifies the redeeming entity, and where the assertion contains a may_act claim, as every ID-JAG issued at a hop that delegates onward does, the AS MUST NOT skip it. Where the assertion is an initial ID-JAG obtained directly through the ID-JAG grant and so contains no may_act claim, the AS MUST apply its own policy to decide whether the authenticated client may redeem it. 5. Attenuation check: The requested scope MUST be a subset of or equal to the scope of the subject_token, where scope is compared as a set of space-delimited values. A request that contains a scope value not present in the subject_token MUST be rejected. Fine-grained narrowing is carried in authorization_details [RFC9396]. Whether a requested authorization_details object is no broader than the corresponding object of the subject_token is defined by that authorization_details type; this profile defines no generic comparison across types. Where the type defines no narrowing relation, or where the AS cannot decide that the requested object is no broader, the AS MUST reject the request. The AS MAY further narrow the granted scope and authorization_details based on policy. Where the subject_token carries a resource claim, the requested resource MUST be the same Liu Expires 6 May 2027 [Page 13] Internet-Draft Delegation Chaining for ID-JAG November 2026 or narrower, and the AS MUST reject a request that names a resource server the subject_token does not. The request of Section 4.3 carries a scope parameter and nothing else to attenuate, so for that request this step applies to scope alone and the authorization_details and resource of the issued Access Token are those the assertion carries, which the AS MAY narrow but MUST NOT widen. 6. Delegation policy: The AS MUST apply its delegation policy to decide whether the authenticated client is permitted to delegate to the target entity named by the actor_token, and which scopes and authorization_details that target entity may receive at all. Policy evaluation takes the authenticated client identity, the target entity identity, and the subject authorization as input. Where policy permits no such delegation the AS MUST reject the request. This check is what authorizes each hop. Where the request is a redemption rather than a delegation, that is, where requested_token_type is urn:ietf:params:oauth:token- type:access_token or the request is the jwt-bearer request of Section 4.3, the delegation part of this step does not apply; the AS instead applies its policy on whether the authenticated client may redeem for the resource server named, and the depth limit below still applies. The may_act claim of the subject_token binds the hop to the entity entitled to present it, but it does not authorize a further delegation, because the target of a delegation is in general chosen at runtime and cannot have been named when the subject_token was issued. The AS MUST determine the current depth of the chain by counting the nested act claims of the subject_token, where a subject_token that carries no act claim is at depth zero, and MUST reject a request whose resulting depth would exceed the maximum the AS is configured to allow. No separate depth claim is needed for this, because the act chain already carries the information. 7. Issuance: At a hop that delegates onward the AS issues the new ID-JAG with the subject unchanged, i.e., the end-user, with the attenuated scope and authorization_details, and with the resource of the request carried forward. The act, may_act, and client_id claims are populated as described in Section 4.5. The lifetime of the issued ID-JAG SHOULD NOT exceed 60 seconds, the limit RECOMMENDED for Delegation Assertions in Section 5.2, and the jti value MUST be unique among the tokens the AS has issued and still tracks. Where the request is a redemption, the AS issues an Access Token instead, with the same subject and the same attenuated privileges, with the aud claim set as described in Section 4.3 for the jwt-bearer request, and with the act claim built as described in Section 4.5. A may_act claim is not meaningful in that Access Token, because nothing redeems it. Liu Expires 6 May 2027 [Page 14] Internet-Draft Delegation Chaining for ID-JAG November 2026 4.5. The Issued ID-JAG The issued ID-JAG carries the end-user as its subject, the attenuated privileges, and the actor chain. The act claim follows Section 4.1 of [RFC8693]: the outermost value represents the current actor, and nested values represent prior actors. At each hop, the AS sets the outermost act value to the authenticated client, that is, the delegating entity at a hop that delegates onward and the entity the assertion was issued to at the last hop, and nests the act claim of the subject_token inside it. The same rule builds the act claim of the Access Token issued at the last hop. The may_act claim follows Section 4.4 of [RFC8693] and is set to the SPIFFE ID carried in the sub claim of the actor_token, i.e., the party entitled to redeem the issued ID-JAG. The client_id claim is set to that same value, so that it matches the client authentication the target entity performs when it presents the ID-JAG, as required by [I-D.ietf-oauth-identity-assertion-authz-grant]. This differs from the delegation example of Appendix A.2 of [RFC8693], in which the act claim of the issued token repeats the subject of the actor_token. That example covers a request for a token the requester will wield itself, where the requester and the actor are the same party. In this profile an intermediate hop requests a token that a downstream delegate will wield, so the actor of the current hop is the requester and the party named by the actor_token is the actor of the next hop. Section 2.1 of [RFC8693] defines the actor_token as the token of the party that is authorized to use the requested security token, which is the downstream delegate here, and Section 1.1 of [RFC8693] leaves whether a composite token is issued, and in what form, to the discretion, policy, and configuration of the authorization server. This profile exercises that discretion. The following is an example of the ID-JAG issued for the first hop, where Agent A delegates to Agent B. The act claim records Agent A, the authenticated client that requested the exchange, while may_act and client_id name Agent B, the entity taken from the actor_token that will present this ID-JAG: Liu Expires 6 May 2027 [Page 15] Internet-Draft Delegation Chaining for ID-JAG November 2026 { "iss": "https://auth.enterprise.net", "sub": "user_original_12345", "aud": "https://auth.enterprise.net", "client_id": "spiffe://cluster.local/ns/ai/sa/agent-db-proxy", "exp": 1776326800, "iat": 1776326740, "jti": "urn:uuid:8e41-4b72-9b2a-111122223333", "resource": "https://db.partner.net", "scope": "reports:read", "authorization_details": [ { "type": "api_access", "actions": ["GET"], "locations": ["/api/v1/reports"] } ], "act": { "sub": "spiffe://cluster.local/ns/ai/sa/agent-researcher" }, "may_act": { "sub": "spiffe://cluster.local/ns/ai/sa/agent-db-proxy" } } The following is an example of the ID-JAG issued for the second hop, where Agent B delegates to Agent C. The act claim nests Agent A inside Agent B, may_act and client_id name Agent C, the scope is unchanged, and the authorization_details have been narrowed from all reports to the single Q3 report. Agent C operates in a different trust domain, so aud names that domain's Authorization Server and does not repeat iss: Liu Expires 6 May 2027 [Page 16] Internet-Draft Delegation Chaining for ID-JAG November 2026 { "iss": "https://auth.enterprise.net", "sub": "user_original_12345", "aud": "https://auth.partner.net", "client_id": "spiffe://partner.local/ns/finance/sa/agent-db-worker", "exp": 1776326900, "iat": 1776326840, "jti": "urn:uuid:f901-2222-3333-444455556666", "resource": "https://db.partner.net", "scope": "reports:read", "authorization_details": [ { "type": "api_access", "actions": ["GET"], "locations": ["/api/v1/reports/q3.pdf"] } ], "act": { "sub": "spiffe://cluster.local/ns/ai/sa/agent-db-proxy", "act": { "sub": "spiffe://cluster.local/ns/ai/sa/agent-researcher" } }, "may_act": { "sub": "spiffe://partner.local/ns/finance/sa/agent-db-worker" } } Because Agent C operates in the partner.local trust domain, the aud claim of this ID-JAG names that domain's Authorization Server rather than the issuer, which is the cross-domain form described in Section 4.1. The partner Authorization Server validates the signature against the signing key of https://auth.enterprise.net, which it obtains through the inter-domain trust relationship between the two. Deployments MAY carry additional claims in the issued ID-JAG, e.g., task context for AI agent workloads, as long as the claims required by [I-D.ietf-oauth-identity-assertion-authz-grant] are present. 5. Optional Variant: Self-Issued Delegation Assertions This section defines an optional variant for hops where a Token Exchange round trip to the AS is not practical. It keeps the protocol shape of the primary mechanism, a signed JWT passed in-band and redeemed together with a workload identity, but moves assertion issuance from the AS to the delegating entities themselves. Liu Expires 6 May 2027 [Page 17] Internet-Draft Delegation Chaining for ID-JAG November 2026 5.1. Applicability The self-issued variant applies to intermediate hops downstream of an authorization that the AS issued, when the delegating entity and the target entity cannot reach a common AS synchronously, for example because they operate in trust domains with no reachable common AS, or because the added latency of a synchronous exchange at every hop is unacceptable for the workload. The end-user's root authorization always originates at the AS. The variant changes only how the hops after that root are bridged, not where the authority comes from. The self-issued variant SHOULD NOT be used when the AS of the chain is reachable. Token Exchange gives the AS the opportunity to validate the actor and enforce attenuation at every hop. The self- issued variant cannot provide those guarantees, see Section 5.4. 5.2. Assertion Format A Delegation Assertion (DA) is a JWT [RFC7519]. A delegating entity, e.g., Agent A, MUST possess authority representing the end-user (sub) before it issues a downstream Delegation Assertion. That authority is either an authorization grant or active token issued by the AS, or an upstream Delegation Assertion whose chain of issuers roots at such a grant or token. Each Delegation Assertion MUST be signed with the private key of the delegating entity's X.509-SVID, see Section 3. A JWT-SVID cannot serve this purpose, because it is signed by the SPIRE server and the workload does not hold that signing key. The Delegation Assertion is a JWS and MUST carry the signing X.509-SVID so that the AS can validate it, for example in the x5c header parameter [RFC7515]. The redeeming AS validates the signature by checking that this X.509-SVID chains to a certificate authority in the SPIFFE trust bundle of the issuer's trust domain, and that the SPIFFE ID carried in the X.509-SVID equals the iss claim of the Delegation Assertion. A Delegation Assertion contains the following claims: * iss: the SPIFFE ID of the delegating entity. * sub: the subject identifier of the initial end-user. * aud: the token endpoint of the AS at which the assertion is redeemed. Liu Expires 6 May 2027 [Page 18] Internet-Draft Delegation Chaining for ID-JAG November 2026 * exp and nbf: a short temporal validity window. A lifetime of 60 seconds or less is RECOMMENDED. * jti: a unique assertion identifier, used for replay prevention. * scope: the attenuated privilege scope, no wider than the privileges of the issuing entity. * authorization_details: optional fine-grained authorization details via [RFC9396], e.g., access to specific API paths or MCP tools. * act: nested actor identities, see Section 5.3. * agent_context: optional agentic context, e.g., task_id, goal, and delegation_depth. The following is an example of an initial-hop Delegation Assertion: { "iss": "spiffe://cluster.local/ns/ai/sa/agent-a", "sub": "user_original_12345", "aud": "https://auth.enterprise.net/oauth/token", "exp": 1776326800, "nbf": 1776326740, "jti": "urn:uuid:8e41-4b72-9b2a-111122223333", "scope": "reports:read", "authorization_details": [ { "type": "api_access", "actions": ["GET"], "locations": ["/api/v1/reports"] } ] } 5.3. Re-Issuance Rules When an intermediate entity, e.g., Agent B, needs to delegate further down the chain, e.g., to Agent C, it MUST NOT forward the original upstream assertion directly and MUST NOT contact the root IdP. It self-issues a new downstream Delegation Assertion following three rules: Liu Expires 6 May 2027 [Page 19] Internet-Draft Delegation Chaining for ID-JAG November 2026 1. Monotonic Scope Attenuation Rule: The re-issued assertion's scope MUST be a subset of or equal to the scope granted to the re- issuing entity, compared as a set of space-delimited values, and its authorization_details MUST be no broader than those granted to the re-issuing entity, as defined by the applicable authorization_details type. Privilege escalation is prohibited. 2. Actor Chain Nesting Rule: In a Delegation Assertion the iss claim is the entity that issues it, which is the current actor of that hop, and the act claim carries the prior actors. The re-issuing entity MUST set the sub member of the act claim to the SPIFFE ID of the entity that issued the assertion it is re-issuing, that is, the iss of the upstream assertion, and MUST set the act member of the act claim to a copy of the act claim of the upstream assertion. Where the upstream assertion carries no act claim, the act member is omitted. The lineage therefore grows by one level at each hop. 3. Audience Re-Binding Rule: The re-issuing entity MUST update the aud claim to target the token endpoint of the downstream AS or resource boundary. The following is an example of a re-issued assertion for the hop Agent B to Agent C. Agent B sets iss to its own SPIFFE ID, records the upstream issuer Agent A as the sole prior actor in act, keeps the scope, and narrows the authorization_details to the single Q3 report. The agent_context member is an example of the deployment-specific claims that Section 4.5 permits; this document does not define it, and an implementation that does not understand it MUST ignore it: Liu Expires 6 May 2027 [Page 20] Internet-Draft Delegation Chaining for ID-JAG November 2026 { "iss": "spiffe://cluster.local/ns/ai/sa/agent-b", "sub": "user_original_12345", "aud": "https://auth.enterprise.net/oauth/token", "exp": 1776326900, "nbf": 1776326840, "jti": "urn:uuid:f901-2222-3333-444455556666", "act": { "sub": "spiffe://cluster.local/ns/ai/sa/agent-a" }, "scope": "reports:read", "authorization_details": [ { "type": "api_access", "actions": ["GET"], "locations": ["/api/v1/reports/q3.pdf"] } ], "agent_context": { "task_id": "task-q3-summary-001", "delegation_depth": 2 } } 5.4. Redemption at the Authorization Server A target entity that received a Delegation Assertion redeems it at the AS named by the aud claim. The request is a Token Exchange request as in Section 4.2, with the Delegation Assertion as the subject_token, subject_token_type set to urn:ietf:params:oauth:token- type:jwt, requested_token_type set to urn:ietf:params:oauth:token- type:access_token, and the redeeming entity's own JWT-SVID as the actor_token. This variant keeps the Token Exchange form rather than the JWT bearer grant of Section 4.3 because the AS builds the act claim of the Access Token from the sub claim of that actor_token, see below, whereas a Delegation Assertion names its issuer and not its presenter. Because the requester is also the party that will wield the issued token, no JWT-SVID is disclosed to any other entity in this variant. The AS validates the Delegation Assertion signature by chaining its X.509-SVID to the SPIFFE trust bundle of the issuer's trust domain, see Section 5.2, checks exp, nbf, and jti, verifies the act chain lineage, and applies the attenuation check and the delegation policy of steps 5 and 6 of Section 4.4 before issuing an Access Token. Steps 3 and 4 of Section 4.4 do not apply to this variant, because the subject_token is a Delegation Assertion rather than an ID-JAG and carries no may_act claim. Liu Expires 6 May 2027 [Page 21] Internet-Draft Delegation Chaining for ID-JAG November 2026 A Delegation Assertion and the ID-JAG of the primary mechanism carry the actor chain in mirror image. In the ID-JAG the AS is the issuer and the act claim carries the current actor together with its predecessors. In the Delegation Assertion the delegating entity is the issuer, so iss is the current actor and act carries only the prior actors. When the AS redeems a Delegation Assertion for an Access Token, it MUST build the act claim of the Access Token with the redeeming entity, identified by the sub claim of its JWT-SVID actor_token, as the outermost actor, nesting the iss of the Delegation Assertion, and nesting inside that the act claim of the Delegation Assertion. The Access Token then carries the full lineage in the same outermost-is-current-actor form used throughout this specification. This variant has weaker guarantees than the primary mechanism, and implementers need to understand them: * Although the end-user's root authorization originates at the AS, see Section 5.1, the Delegation Assertion that reaches the AS at redemption is self-issued and the AS did not issue it. The AS cannot tell from the assertion alone whether its chain of issuers truly roots at a grant the AS issued. The request defined in Section 2.1 of [RFC8693] carries a single subject_token and leaves no place for the end-user's own token, so the AS SHOULD corroborate the root by means available to it, for example by matching the sub claim against a grant it issued within the lifetime of the assertion. * Attenuation performed by intermediate entities is not independently verifiable. The AS trusts the signatures of the self-issued assertions and applies its own policy, but a compromised intermediate can misstate the privileges it inherited. * A Delegation Assertion does not name the entity entitled to present it. Presenters are authenticated, but any holder can attempt redemption. Short lifetimes and policy restrictions limit this exposure but do not remove it. 6. Security Considerations 6.1. Audience and Hop Binding The aud claim of every ID-JAG in the chain identifies the AS that redeems it, which prevents cross-service injection of ID-JAGs into other security domains. The may_act claim additionally binds each ID-JAG to the single entity entitled to present it. An ID-JAG stolen in transit or from a compromised workload cannot be used by a different workload, because that workload cannot authenticate as the Liu Expires 6 May 2027 [Page 22] Internet-Draft Delegation Chaining for ID-JAG November 2026 entity may_act names, and the AS rejects the request at the hop binding check of Section 4.4. For self-issued Delegation Assertions, the aud claim MUST be strictly locked to the token endpoint of the AS to prevent cross-service injection or replay. The two mechanisms therefore use different audience forms, the issuer identifier for ID-JAGs and the token endpoint for Delegation Assertions; both are permitted by Section 2.4.2 of [I-D.ietf-oauth-identity-chaining]. Each is fixed per mechanism, so a token of one mechanism is not a valid audience match for the other and the two cannot be substituted. 6.2. Transfer of the Target Entity's JWT-SVID At an intermediate hop the actor_token is the JWT-SVID of the target entity, so the target entity discloses a JWT-SVID to the entity that delegates to it. A JWT-SVID is a bearer credential, and whoever holds one can present it as that workload to any party named in its aud claim. [SPIFFE-JWT-SVID] warns that a JWT-SVID sent to one audience can be replayed to another if more than one audience is present, and that interception of a JWT-SVID grants an attacker the full privileges it affords. This exposure is narrower than a general disclosure of the target entity's identity credential, and implementations MUST keep it narrow: * The target entity MUST mint the JWT-SVID it discloses with a single aud value identifying the AS that will process the exchange, and MUST NOT disclose a JWT-SVID minted for any other audience. * The disclosed JWT-SVID SHOULD have the shortest lifetime the infrastructure supports, and the delegating entity MUST NOT retain it after the exchange completes. * The audience check that step 2 of Section 4.4 requires is what prevents a JWT-SVID minted for one AS from being used to request an ID-JAG at another. * The AS MUST record the jti of every actor_token it accepts and MUST reject reuse of a jti it has already accepted, which limits the value of a disclosed JWT-SVID to a single exchange. Even with these measures a compromised delegating entity can request an ID-JAG naming an arbitrary target. That is why the delegation policy check of Section 4.4, and not the actor_token, is what authorizes a hop: the actor_token determines who may redeem the Liu Expires 6 May 2027 [Page 23] Internet-Draft Delegation Chaining for ID-JAG November 2026 issued ID-JAG, and policy determines whether issuing it is permitted at all. Deployments in which a target entity is unwilling to disclose even an audience-pinned, single-use JWT-SVID to its upstream peer SHOULD use the self-issued variant of Section 5, in which each entity signs with its own X.509-SVID private key and discloses no bearer credential to any peer. 6.3. Monotonic Attenuation Downstream privilege scopes can only be equal to or narrower than upstream permissions. The AS enforces this at every hop of the primary mechanism, so no hop can widen the privileges it inherited. Two limits remain. Attenuation constrains only what a hop adds, not the breadth of the root authorization the end-user granted, and for authorization_details it is only as strong as the narrowing relation the applicable type supports, see step 5 of Section 4.4. In the self-issued variant, attenuation is asserted by the delegating entities and checked only at redemption time, see Section 5.4. 6.4. Replay Prevention The AS MUST enforce jti uniqueness for the tokens it issues and for every subject_token, actor_token, and Delegation Assertion it accepts, retaining each recorded jti at least until the corresponding token expires. Self-issued Delegation Assertions MUST have a short lifespan and SHOULD NOT exceed 60 seconds. 6.5. Transport and Confidentiality ID-JAGs and Delegation Assertions are credentials passed over inter- agent transports, e.g., HTTP headers, gRPC metadata, or MCP payloads. They MUST be sent over TLS or an equivalently protected transport. They MUST NOT be logged or persisted in plaintext by intermediaries. 6.6. Workload Identity Compromise Client authentication and the actor_token together bind every hop of the chain to workload identities. A compromised workload can act within the privileges delegated to it. JWT-SVIDs are short-lived and rotated by the infrastructure, which limits the window of a stolen SVID. Compromise of an intermediate workload is bounded by the monotonic attenuation already applied upstream, but AS policy SHOULD also cap the total delegation depth, counted from the act chain as described in Section 4.4, and the privileges available to each hop. Compromise of a delegating entity additionally exposes the audience- pinned JWT-SVIDs that its downstream peers disclosed to it, as described in Section 6.2. A compromised workload therefore affects Liu Expires 6 May 2027 [Page 24] Internet-Draft Delegation Chaining for ID-JAG November 2026 the chain in two directions, and the AS SHOULD treat a delegation request carrying an actor_token jti it has already accepted as an indication of compromise. 7. Privacy Considerations The act claim of an issued token discloses the full delegation topology to every party that receives it, namely which workload identities participated, in which trust domains, and in what order. A resource server in one trust domain therefore learns the internal structure of a chain that originated in another. This disclosure is inherent to the delegation semantics the act claim provides, and it is bounded by the SPIFFE IDs themselves, which are infrastructure identifiers rather than user identifiers. Deployments that consider the topology sensitive SHOULD have their AS truncate the act chain beyond a configured depth or replace intermediate actors with a trust-domain-level identifier, at the cost of weaker attribution. The subject identifier of the end user crosses every trust domain the chain passes through, and it is the one element that correlates the activity of all the workloads in the chain back to a single person. The end user has no visibility into that propagation. An AS that issues an ID-JAG for a trust domain other than its own SHOULD apply its own policy on which subject identifiers may leave the domain, and deployments SHOULD prefer pairwise identifiers over a global user identifier so that correlation across unrelated chains is not possible. The actor_token transfer of an intermediate hop additionally discloses a workload's JWT-SVID to its upstream peer; Section 6.2 constrains that disclosure. The self-issued variant of Section 5 discloses the X.509-SVID certificate of every delegating entity in the chain, since each Delegation Assertion carries its signing certificate; the certificate is public information within the SPIFFE trust domain but does reveal which workloads exist. 8. IANA Considerations This document has no IANA actions. 9. References 9.1. Normative References [I-D.ietf-oauth-identity-assertion-authz-grant] Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz- Liu Expires 6 May 2027 [Page 25] Internet-Draft Delegation Chaining for ID-JAG November 2026 grant-06, 30 October 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-17, 19 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . Liu Expires 6 May 2027 [Page 26] Internet-Draft Delegation Chaining for ID-JAG November 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [SPIFFE-ID] SPIFFE Project, "SPIFFE ID Standards", 30 October 2026, . [SPIFFE-JWT-SVID] SPIFFE Project, "JWT-SVID Standards", 30 October 2026, . [SPIFFE-X509-SVID] SPIFFE Project, "X.509-SVID Standards", 30 October 2026, . 9.2. Informative References [I-D.ietf-oauth-spiffe-client-auth] Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft- ietf-oauth-spiffe-client-auth-02, 15 June 2026, . [OpenID.Core] Sakimura, N., Bradley, J., Jones, M. B., de Medeiros, B., and C. Jayawardena, "OpenID Connect Core 1.0 incorporating errata set 1", November 2014, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . Liu Expires 6 May 2027 [Page 27] Internet-Draft Delegation Chaining for ID-JAG November 2026 Appendix A. Complete End-to-End Use Case: Multi-Hop Financial Research Agent Workflow To illustrate the practical application of this document, this appendix provides a step-by-step walkthrough of a multi-hop AI agent workflow. A.1. Scenario Overview An enterprise user (alice@enterprise.com) wants to generate a Q3 financial summary. The workflow involves the following entities: 1. User / Client App: Initiates the high-level request. 2. Agent A (Research Coordinator, spiffe://cluster.local/ns/ai/sa/ agent-researcher): Receives the user goal and delegates raw data retrieval. 3. Agent B (Database Proxy Agent, spiffe://cluster.local/ns/ai/sa/ agent-db-proxy): Receives the delegated task and delegates specific query execution to a specialized worker. 4. Agent C (Financial DB Worker / MCP Server, spiffe://partner.local/ns/finance/sa/agent-db-worker): Executes the underlying database query. Agent C runs in a partner trust domain with its own Authorization Server, which is what makes the last hop a cross-domain one. 5. Enterprise Authorization Server (https://auth.enterprise.net): Issues the initial ID-JAG to Agent A and processes the exchanges at the first two hops, including identity validation, attenuation, and actor chain generation. 6. Partner Authorization Server (https://auth.partner.net): Redeems the ID-JAG issued for Agent C and issues the final Access Token. 7. Financial Database Resource Server (https://db.partner.net): Serves the report data. A.2. Step-by-Step Protocol Flow Step 1 (Initial Authentication): Alice authenticates to the enterprise AS via OpenID Connect [OpenID.Core]. Agent A requests its initial ID-JAG from that AS with the ID-JAG grant [I-D.ietf-oauth-identity-assertion-authz-grant], presenting Alice's ID Token as the identity assertion, requesting the scope "reports:read mail:send", and setting audience to https://auth.enterprise.net so that the issued ID-JAG names the AS at Liu Expires 6 May 2027 [Page 28] Internet-Draft Delegation Chaining for ID-JAG November 2026 which Agent A will present it in Step 2. Step 2 (Hop 1, Agent A to Agent B): Agent A decides to delegate the data retrieval and obtains from Agent B a JWT-SVID whose aud is https://auth.enterprise.net. Agent A authenticates to the enterprise AS and sends the Token Exchange request of Section 4.2 with subject_token set to its ID-JAG, actor_token set to Agent B's JWT- SVID, audience set to https://auth.enterprise.net, resource set to https://db.partner.net, scope set to reports:read, and authorization_details limiting access to /api/v1/reports. The enterprise AS validates the request as described in Section 4.4. The subject_token carries no may_act claim, because it is the initial ID- JAG obtained in Step 1, so the AS relies on its delegation policy to decide that Agent A may delegate to Agent B. It issues the ID-JAG shown in the first example of Section 4.5, with act recording Agent A and may_act and client_id naming Agent B. Agent A passes the ID-JAG to Agent B over the A2A transport. Step 3 (Hop 2, Agent B to Agent C): Agent B needs the specialized worker for the actual query and obtains from Agent C a JWT-SVID whose aud is https://auth.enterprise.net, the AS that will process this exchange. It presents the received ID-JAG as the subject_token and Agent C's JWT-SVID as the actor_token to that AS, with audience set to https://auth.partner.net, resource set to https://db.partner.net, scope set to reports:read, and authorization_details narrowing access to the single Q3 report at /api/v1/reports/q3.pdf. The enterprise AS verifies that Agent B, the authenticated client, matches the may_act claim of the subject_token, applies its delegation policy for the hop from Agent B to Agent C, confirms that the requested scope is unchanged and that the narrowed authorization_details are no broader than those of the subject_token, and issues the ID-JAG shown in the second example of Section 4.5, whose aud names the partner Authorization Server because Agent C is in the partner.local trust domain. Agent B passes it to Agent C. Step 4 (Final Redemption at Agent C): Agent C presents the received ID-JAG to https://auth.partner.net, the AS named by its aud claim, as the assertion of a JWT bearer request as described in Section 4.3, requesting scope reports:read. This is the last hop, so Agent C delegates to no one, sends no actor_token, and discloses no JWT-SVID, not even its own. The partner AS validates the ID-JAG signature against the signing key of https://auth.enterprise.net, verifies that Agent C, the authenticated client, matches the may_act claim of the assertion, applies the same attenuation and policy checks, and issues an Access Token whose aud is https://db.partner.net, the resource server named by the resource claim carried forward since Step 2, and which carries the complete lineage: Liu Expires 6 May 2027 [Page 29] Internet-Draft Delegation Chaining for ID-JAG November 2026 { "iss": "https://auth.partner.net", "sub": "user_original_12345", "aud": "https://db.partner.net", "exp": 1776326950, "iat": 1776326890, "jti": "urn:uuid:1a2b-3c4d-5e6f-708192a3b4c5", "scope": "reports:read", "authorization_details": [ { "type": "api_access", "actions": ["GET"], "locations": ["/api/v1/reports/q3.pdf"] } ], "act": { "sub": "spiffe://partner.local/ns/finance/sa/agent-db-worker", "act": { "sub": "spiffe://cluster.local/ns/ai/sa/agent-db-proxy", "act": { "sub": "spiffe://cluster.local/ns/ai/sa/agent-researcher" } } } } Step 5 (Execution): Agent C presents the Access Token to the Financial Database Resource Server. The Resource Server validates the audience and reads the act chain, achieving verifiable multi-hop provenance: User Alice -> Agent-Researcher -> Agent-DB-Proxy -> Agent-DB-Worker. The chain spans two trust domains, and the Resource Server can see from the act claim which workloads in which domains handled the request, without either domain having to expose its internal authorization decisions to the other. Contributors Aaron Parecki Okta Email: aaron@parecki.com Acknowledgments The author thanks Hongru Zhu, Hui Xue, and Suresh Krishnan for enlightening discussions. Liu Expires 6 May 2027 [Page 30] Internet-Draft Delegation Chaining for ID-JAG November 2026 Author's Address Dapeng Liu Alibaba Email: max.ldp@alibaba-inc.com Liu Expires 6 May 2027 [Page 31]