Who’s on FirstChoose a flow

Flows / Delegation chains

Identity chaining across domains

Carry who-is-this-for across an organizational boundary, with each side keeping control of its own tokens.

Based ondraft-ietf-oauth-identity-chainingWG draft, revision -17Guide reviewedNovember 2026

Sources and review details
This page
Implementation guideAn explanation, not a specification
Primary specification
Identity and Authorization Chaining Across DomainsWG draft · Revision -17, July 2026
All 6 specifications
3 published, 3 drafts
Flow maturity
EmergingWhat the rating means
Human involvement
With or without a human
Review
Checked against sources in November 2026How it was checked

Token exchange works inside one trust domain, where a single authorization server can mint a token for any hop. Agent workflows do not stay inside one domain. An agent in company A calls a service run by company B. Company B will not accept company A’s tokens, and should not.

Identity chaining combines two existing pieces to cross the boundary. In its home domain, the agent uses token exchange to obtain a short-lived JWT authorization grant addressed to the other domain’s authorization server. It then presents that grant to the other side using the JWT bearer grant, and receives an access token that the second domain issued under its own policy. Each domain validates only what it issued or explicitly agreed to trust, and the pattern repeats for every further boundary.

The specification is through IETF approval and waiting in the RFC Editor’s queue.

Step by step

9 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.

Sequence diagram4 participants, 9 steps
  • Direct call
  • Response
  • Local action

Drag to see every party and step. Tap a step to jump to its explanation.

1Holds a domain A token2Token exchange:grant for B3Policy: may this leave?4JWT authorizationgrant5JWT bearer grant6Trust A’s key; map claims7Access token (domain B)8API call with B’s token9200 OK

  1. 1AgentLocal action

    The agent has authority at home, and needs it elsewhere

    The agent holds a token issued in domain A, for a user or for itself. It needs to call an API protected by domain B’s authorization server.

    Who holds what after this step

    Agent
    newtoken (domain A)

    Parties not listed hold none of this flow’s credentials at this point.

  2. 2AgentAS, domain ADirect call

    The agent asks its home server for a grant aimed at domain B

    A token exchange request (RFC 8693) whose target is the other domain’s authorization server.

    POST /token HTTP/1.1
Host: as.a.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<token from domain A>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&requested_token_type=urn:ietf:params:oauth:token-type:jwt
&audience=https://as.b.example
&scope=orders.read

    Who holds what after this step

    Agent
    token (domain A)

    Parties not listed hold none of this flow’s credentials at this point.

  3. 3AS, domain ALocal action

    Domain A decides what crosses its boundary

    The home authorization server controls outbound trust: which clients may obtain grants for which external domains, and which claims about the user are released.

    Who holds what after this step

    Agent
    token (domain A)

    Parties not listed hold none of this flow’s credentials at this point.

  4. 4AS, domain AAgentResponse

    A short-lived grant addressed to domain B

    Signed by domain A. Its audience is domain B’s authorization server and nothing else. It is not an access token and no API should accept it.

    {
  "iss": "https://as.a.example",
  "sub": "alice@a.example",
  "aud": "https://as.b.example",
  "client_id": "research-agent",
  "scope": "orders.read",
  "jti": "c3f1…",
  "exp": 1794268920
}

    Who holds what after this step

    Agent
    token (domain A)newJWT grant (aud: AS B)

    Parties not listed hold none of this flow’s credentials at this point.

  5. 5AgentAS, domain BDirect call

    The agent presents the grant across the boundary

    An RFC 7523 assertion grant at domain B’s token endpoint. The agent also authenticates as a client known to domain B.

    POST /token HTTP/1.1
Host: as.b.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=<JWT authorization grant>
&resource=https://api.b.example

    Who holds what after this step

    Agent
    token (domain A)used upJWT grant (aud: AS B)

    Parties not listed hold none of this flow’s credentials at this point.

  6. 6AS, domain BLocal action

    Domain B applies its own policy

    Domain B verifies the signature against keys it has agreed to trust for domain A, checks it is the audience, and maps the incoming subject and claims to its own. It is free to grant less than was asked.

    Who holds what after this step

    Agent
    token (domain A)

    Parties not listed hold none of this flow’s credentials at this point.

  7. 7AS, domain BAgentResponse

    Domain B issues its own token

    An ordinary access token, issued and revocable by domain B, with domain B’s idea of who the subject is.

    Who holds what after this step

    Agent
    token (domain A)newaccess token (domain B)

    Parties not listed hold none of this flow’s credentials at this point.

  8. 8AgentAPI, domain BDirect call

    The agent calls the remote API

    The API validates a token from its own authorization server. It never sees anything issued by domain A.

    Who holds what after this step

    Agent
    token (domain A)access token (domain B)

    Parties not listed hold none of this flow’s credentials at this point.

  9. 9API, domain BAgentResponse

    The remote API responds

    Either domain can end the arrangement independently: A by refusing to issue grants, B by refusing to honor them.

    Who holds what after this step

    Agent
    token (domain A)access token (domain B)

    Parties not listed hold none of this flow’s credentials at this point.

Watch out for

  • Trust between the two authorization servers is set up in advance: keys, issuer names, and which claims are honored. The specification does not create that trust for you.
  • Identifiers rarely match across domains. Decide how subjects are mapped, and what happens when a mapping does not exist.
  • Each hop can add or drop claims. Make sure the receiving side does not treat a claim as verified merely because it arrived.
  • Keep the grant short-lived and single-audience. It is a bearer credential for obtaining tokens.

Relation to ID-JAG

ID-JAG is a profile of this pattern for one common case: the first authorization server is an enterprise identity provider and the input is the user’s single sign-on assertion. The WIMSE working group’s agent architecture document recommends identity chaining or ID-JAG whenever an agent crosses a trust domain.

Standards in play

See the full tracker for status and links.

RFCRFC 8693

Token Exchange

The primitive under on-behalf-of flows, ID-JAG, identity chaining and transaction tokens.

WG draftdraft-ietf-wimse-aims

AI Identity Management System (AIMS)

The closest thing to an IETF reference architecture for agent authentication and authorization. Its opening position: agents are workloads.

Enterprise-managed (ID-JAG)

The company identity provider decides which agents may reach which apps for which employees. No per-app consent screens.

Human presentEmerging

Token exchange

Trade the token you were given for a new one that names both the user and the service now acting for them.

With or without a humanStable standards

Transaction tokens

Inside your own infrastructure, replace the access token with a short-lived token that pins down one transaction and travels the whole call chain.

With or without a humanEmerging

Workload identity federation

Your agent uses an identity established by its runtime to obtain short-lived access from a system that trusts that identity.

No humanStable standards