]> Alibaba

max.ldp@alibaba-inc.com

Security Web Authorization Protocol OAuth Token Exchange Delegation ID-JAG SPIFFE AI Agents Workload Identity 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 . An optional variant based on self-issued Delegation Assertions is defined for hops where the Authorization Server is not reachable. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Individual Draft mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 and the Identity Assertion JWT Authorization Grant (ID-JAG) 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. 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 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 .

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 .
2. OAuth 2.0 Token Exchange 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 () to bind each issued ID-JAG to the entity entitled to redeem it at the next hop, and the act claim () 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 , which is itself a profile of . Identity chaining combines OAuth 2.0 Token Exchange with the JWT bearer grant of 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 . 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 , as requires. That form is defined in , and states the checks that apply to both. 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 . That variant offers weaker guarantees and supplements, but does not replace, the mechanism of .

Terminology This document uses the terms "authorization server" (AS), "client", "resource server" (RS), and "access token" defined in , the Token Exchange parameters defined in , the JWT bearer grant parameters defined in , and the act and may_act claims defined in and . In addition, this document defines the following roles and credentials:

ID-JAG:

An Identity Assertion JWT Authorization 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 .

Delegation Assertion (DA):

A short-lived JWT self-issued by a delegating entity in the optional variant of , 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 when, and only when, they appear in all capitals, as shown here.

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 . SPIRE's Kubernetes workload registrar assigns IDs of the form: /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 . JWT-SVIDs are short-lived by design . SPIFFE defines a second credential form for the same identity, the X.509-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 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 . 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 . 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 and .

Delegation Chaining

Overview The chain starts like any ID-JAG flow. The end-user authenticates to the AS, for example with OpenID Connect . The first workload, Agent A, requests its initial ID-JAG with the ID-JAG 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 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.

One hop of the delegation chain | | | 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 | ]]>

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 . The target entity redeems the ID-JAG there. The processing requirements of 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.

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 , with the following parameters: The subject_token, subject_token_type, actor_token, actor_token_type, requested_token_type, and audience parameters are REQUIRED in this profile, notwithstanding that 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 . The processing rules of 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 . The resource parameter remains OPTIONAL as in and is constrained by step 5 of when present. Using the value urn:ietf:params:oauth:token-type:id-jag for subject_token_type is an extension of , 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 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 . The scope and authorization_details 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 requires. The authorization_details parameter carries the fine-grained narrowing, for example restricting access to a single resource, and is encoded as specified in . The audience parameter has a single meaning throughout this profile: it names the entity at which the issued token will be presented, as 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 , 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 , 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 . The actor_token identifies the party that will wield the issued ID-JAG, which is the reading 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 . 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 and . 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 . The response follows . The issued ID-JAG is returned in the access_token parameter and token_type is set to N_A.

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 , as requires and as describes: This request, as defined here, uses the parameter values and encodings of 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 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 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 , and an assertion that fails validation yields the invalid_grant error of . 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 .

Authorization Server Processing Requirements Upon receiving a request of either form, the delegation request of or the last-hop request of , the AS executes the following verification and policy evaluation pipeline. These requirements answer the questions that 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 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 . 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 carries none and skips this step. The actor_token MUST be a 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 , 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 , 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 , including signature, issuer, audience, expiration, not-before, and jti. The aud claim of the subject_token MUST identify the AS itself. Where the subject_token carries a client_id claim, that claim MUST identify the authenticated client, as 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 , 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 , 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 . 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 or narrower, and the AS MUST reject a request that names a resource server the subject_token does not. The request of 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 , 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 . The lifetime of the issued ID-JAG SHOULD NOT exceed 60 seconds, the limit RECOMMENDED for Delegation Assertions in , 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 for the jwt-bearer request, and with the act claim built as described in . A may_act claim is not meaningful in that Access Token, because nothing redeems it.

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 : 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 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 . This differs from the delegation example of , 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. 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 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: 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: 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 . 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 are present.

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.

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 .

Assertion Format A Delegation Assertion (DA) is a JWT . 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 . 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 . 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.
• 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 , e.g., access to specific API paths or MCP tools.
• act: nested actor identities, see .
• agent_context: optional agentic context, e.g., task_id, goal, and delegation_depth.

The following is an example of an initial-hop Delegation Assertion:

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:

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 permits; this document does not define it, and an implementation that does not understand it MUST ignore it:

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 , 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 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 , 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 before issuing an Access Token. Steps 3 and 4 of 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. 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 , 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 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.

Security Considerations

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 entity may_act names, and the AS rejects the request at the hop binding check of . 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 . 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.

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. 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 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 , and not the actor_token, is what authorizes a hop: the actor_token determines who may redeem the 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 , in which each entity signs with its own X.509-SVID private key and discloses no bearer credential to any peer.

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 . In the self-issued variant, attenuation is asserted by the delegating entities and checked only at redemption time, see .

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.

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.

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 , 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 . A compromised workload therefore affects 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.

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; constrains that disclosure. The self-issued variant of 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.

IANA Considerations This document has no IANA actions.

References Normative References SPIFFE Project SPIFFE Project SPIFFE Project This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] Okta Independent Ping Identity This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523). This pattern is informally referred to as Cross-App Access (XAA). This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. Informative References A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. Defakto Security Defakto Security NIST IBM Cisco Systems This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521], the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523], and OAuth 2.0 Attestation-Based Client Authentication [I-D.draft-ietf-oauth-attestation-based-client-auth] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs, WIT-SVIDs, or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets.

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.

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.

Step-by-Step Protocol Flow Step 1 (Initial Authentication): Alice authenticates to the enterprise AS via OpenID Connect . Agent A requests its initial ID-JAG from that AS with the ID-JAG 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 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 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 . 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 , 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 , 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 , 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: 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 Okta

aaron@parecki.com

Acknowledgments The author thanks Hongru Zhu, Hui Xue, and Suresh Krishnan for enlightening discussions.