IETF · 19 July 2026
draft-ietf-oauth-identity-chaining-17
A. Schwenkschuster, P. Kasselman, K. Burgin, M. Jenkins, B. Campbell, A. Parecki
Enterprise agents that read mail in tenant A and file tickets in SaaS B are exactly this pattern. XAA is a profile of this draft for IdP-brokered app-to-app access.
At a glance
Actors
01
A request that starts in trust domain A needs to call a resource in trust domain B, carrying who the user is and what was granted, without flattening everything into a single AS. Enterprise agents that read mail in tenant A and file tickets in SaaS B are exactly this pattern.
This draft combines RFC 8693 and RFC 7523. XAA is a profile of it for IdP-brokered app-to-app access. Still an I-D in the RFC Editor queue as of 19 July 2026 (rev 17) — cite the draft until an RFC number exists.
02
AS A must be willing to mint a JWT authorization grant whose audience is AS B. AS B must trust AS A's signatures as a grant issuer (not as an access-token issuer). The client in A never presents A's access token to B's RS. Repeat at every domain hop; attenuate every time.
03
Client in A performs token exchange at AS A to obtain a JWT authorization grant audience-restricted to AS B. Client presents that JWT to AS B using the RFC 7523 JWT bearer grant. AS B issues an access token for its resource. draft-ietf-oauth-identity-chaining-17, 19 July 2026, intended Proposed Standard, RFC Editor state In Progress / awaiting first editor on the WG list.
04
Flow 1
User delegates to the client at AS A. Client holds an access token for A's APIs.
Client token-exchanges at AS A: requested token type = JWT grant, audience = AS B issuer.
Client POSTs jwt-bearer assertion to AS B's token endpoint, plus resource=B's API.
AS B validates the grant (trust in A, aud=B, exp, policy) and issues an at+jwt for its RS.
Client calls B's RS with that access token, never with A's token.
05
Preserves identity (subject) and authorization context across domain boundaries. Client authentication happens at each AS. User authentication already happened in domain A (OIDC).
06
First hop.
Second hop (7523).
IdP-shaped profile of this pattern; ID-JAG is the grant.
Inside one domain, Txn-Tokens carry purpose; chaining is for crossing AS trust domains.
Four-party AAuth is a different federation (PS to resource AS), not this draft.
07
The whole point is not to do that. Audience and issuer checks at B's RS will (must) fail.
IESG: RFC Editor queue. Do not invent a private cross-domain format if you can wait; do not claim it is already an RFC.
08
draft-ietf-oauth-identity-chaining-17, 19 July 2026, expires 20 January 2027, OAuth WG, Proposed Standard target, RFC Editor In Progress. https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/. Implement with pinned revision; expect an RFC number, not wire churn, if the queue completes cleanly.
As of 19 July 2026 this document was in the RFC Editor queue (awaiting first editor) targeting Proposed Standard. Still cite it as an I-D until an RFC number is assigned. Do not invent a private cross-domain token format if you can wait for this.