OAuth Token Exchange and Identity Chaining

OAuth 2.0 Token Exchange (RFC 8693) and the identity chaining specifications built on it carry a user's identity and authorization context across service boundaries, so that each hop in a call chain can decide access based on who originally made the request rather than on the privileges of whichever service forwarded it. Token exchange provides the base primitive, trading one token for another, and the specifications profiled below define what belongs in the resulting token and how far it should travel. The problem predates AI agents and arises in any architecture where a service calls another service on a user's behalf, but agent workflows make it acute: a single request may traverse an orchestrator, several sub-agents, and multiple external APIs, and every hop is an opportunity to lose the original principal or silently amplify privilege.

Propagation Within a Trust Domain

Transaction Tokens (TraTs) address propagation inside a single trust domain. At the domain boundary, the incoming external access token is exchanged once for a short-lived signed JSON Web Token (JWT) that carries immutable per-request context, and internal services pass that token between them instead of the original bearer token. Because the context is fixed at the boundary and signed, a compromised or buggy downstream service cannot widen the request's scope, and the audit trail for the entire internal call chain shares one correlatable identifier.

The agent extension adds the two claims that agentic workloads need: actor, identifying the agent performing the action, and principal, identifying the human who initiated it. This distinction is what makes dual-attribution audit logging mechanically possible rather than a convention each service implements differently.

Delegation Across Trust Boundaries

Transaction Tokens deliberately stop at the domain edge. Two specifications handle what happens beyond it.

Identity Chaining combines RFC 8693 token exchange with RFC 7523 JWT authorization grants so that an identity assertion issued in one organization's trust domain can be presented to an authorization server in another. It is the general cross-domain pattern and does not assume anything about agents, and the most mature of the specifications here: approved for publication as a Proposed Standard in June 2026 and awaiting its RFC number.

ID-JAG (Identity Assertion JWT Authorization Grant) is the narrower, more deployed case: an enterprise identity provider issues a JWT authorization grant that a downstream resource server honours without further user interaction. This is the mechanism that bridges enterprise SSO into agent authorization without distributing long-lived credentials or static API keys, and it is the basis of the enterprise authorization extension in Model Context Protocol.

OrchestratorAuthorization serverSub-agent or serviceAPI, another domain the incoming tokena transaction token called with a narrower tokenexchanged again, on the way outa grant that domain acceptsthe original user, still named
Each boundary is an exchange: the incoming token becomes one that names the agent and the human both, and is exchanged again on the way out of the trust domain.

Reducing Authority at Each Hop

Chaining a token forward preserves context but does not by itself reduce privilege. Attenuating Agent Tokens propose monotonically attenuating JWTs: any holder can derive a strictly more restrictive token offline, without a round trip to the authorization server. An orchestrating agent can therefore hand each sub-agent only the subset of its own authority that the sub-task requires, and the reduction is cryptographically verifiable rather than merely intended. For recursive delegation this is the difference between least privilege as a design goal and least privilege as an enforced property.

Delegation Chain Integrity

The chain itself becomes security-relevant data. The IETF Workload Identity in Multi-System Environments (WIMSE) architecture carries a security context recording the original principal and every intermediate hop, and draft-liu-ai-agent-authorization-integration, an individual draft, proposes an explicit delegation_chain claim for end-to-end auditability.

Recording the chain creates a new attack surface. Delegation chain splicing, raised on the IETF OAuth Working Group's mailing list, is the case in which a compromised intermediary presents a subject token and an actor token taken from different delegation contexts to the token exchange endpoint, so that the token it receives records a delegation that never happened. RFC 8693 leaves it to the authorization server's policy whether the two inputs belong together, so that check has to be made deliberately, and implementations have to verify the chain's integrity rather than merely read it, which means each hop's assertion needs to be independently verifiable rather than assembled from claims a previous hop could rewrite. The Delegation Receipt Protocol approaches the adjacent question of user-to-operator trust, producing evidence that a user authorized an operator to act, which complements rather than replaces chain verification.

Choosing Between the Mechanisms

The specifications are complementary and the selection follows the topology of the call, not the technology in it. Transaction Tokens apply within one trust domain and are the right default for internal service-to-service and orchestrator-to-sub-agent calls. Identity Chaining applies when the call crosses organizational boundaries, with ID-JAG as the specific enterprise-IdP-to-resource-server case. Attenuation is orthogonal to both and applies wherever authority should narrow as it is passed on. All of them carry an authorization that already exists; none of them creates a new one, so where an action needs a fresh human decision rather than propagated context, the mechanism is Client-Initiated Backchannel Authentication (CIBA): a separate authorization request the user approves out-of-band, whose result then enters the chain as its own grant. In all cases the resulting context is only useful if something evaluates it, which is where Policy-Based Access Control (PBAC) and the AuthZEN decision interface come in. The token carries the facts, and the policy engine decides what they permit.

Summary

Token chaining is the layer that makes multi-hop authorization auditable, and it is ahead of the agent-specific standards that depend on it. Identity Chaining is approved for publication, Transaction Tokens has Working Group consensus, and ID-JAG is a Working Group draft that is still changing, while the agent-oriented drafts remain individual submissions. Organizations building either microservice architectures or AI agent deployments can build on Transaction Tokens and ID-JAG before they are final, provided they pin the draft revision an implementation follows and re-test when a new one appears; that cost is small for Transaction Tokens and real for ID-JAG. The agent-specific claim extensions can then be treated as additive. The design decision worth making early is architectural rather than protocol-level: fix the request context at the trust domain boundary, and require that authority narrow rather than persist as it is delegated.