Extending ID-JAG to support public clients is an open topic for discussion. I encourage you to read these issues and chime in with additional use cases, concerns, or feedback
https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/85 https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/113 The gateway scenario you outlined is similar to one where folks need to make a second hop after exchanging the ID-JAG for an access token and no longer have access to the original identity assertion to obtain a new ID-JAG. I've been exploring this scenario as an identity continuation pattern ( https://notes.karlmcguinness.com/notes/identity-continuation-assertion/). A key premise of ID-JAG is that re-subjecting across trust domains is a mint and not an attenuation ( https://notes.karlmcguinness.com/notes/re-subjecting-is-a-mint-not-an-attenuation/ ). This may not be relevant to your specific gateway deployment scenarios, but it is common in deployments where a gateway fronts existing SaaS apps for example. I'm not super happy with the solution I arrived at ( https://mcguinness.github.io/draft-mcguinness-oauth-id-continuation-assertion/draft-mcguinness-oauth-id-continuation-assertion.html and for this reason I haven't submitted it yet as an I-D because it still needs workshopping. I'm sharing this only to see if it aligns with your use case. I expect smarter people will find better solutions as this particular solution isn't pretty. For scenarios that don't need re-subjecting then an attentuation based soluton may be attractive but that it outside the scope of the ID-JAG profile. -Karl On Wed, Jul 22, 2026 at 8:58 AM morganLR <morganLR= [email protected]> wrote: > Eric, > > The dilemma is real and I do not think you missed a mechanism. It is worth > naming why it arises structurally: an identity assertion is audience-locked > to the party it was issued to, and delegation through an intermediary > requires either re-minting at the issuer or a way for the intermediary's > participation to be first-class in the exchange. Section 4.3.3 as written > admits neither, so every gateway hop reproduces your dilemma. > > Two resolution families exist, and the draft could name which it intends. > > Within the current model, RFC 8693 already has the missing piece: the > actor_token. A composite exchange where the gateway authenticates as > itself, presents the agent's assertion as subject_token and its own > credential as actor_token, and the IdP applies the audience check to the > subject token's original audience while separately authorizing the actor as > a registered intermediary for that audience, resolves your topology without > new machinery. The cost is that the IdP must now hold policy about which > intermediaries may act for which clients, and the exchange remains a > per-upstream, per-hop round trip to the IdP: the gateway mints one ID-JAG > per upstream AS, on the critical path. > > The other family carries the delegation as a verifiable artifact instead > of re-minting it: the agent delegates narrowed authority to the gateway in > a form the upstream can verify directly against the original issuer's key, > so the intermediary attenuates rather than exchanges, and no per-hop trip > to the IdP exists. That property class (attenuation verifiable from the > artifact alone, no runtime callback to the issuing side, possession bound > at each hop) is what R1, R3, and R4 in > draft-reece-wimse-cross-org-delegation describe, and gateway aggregation is > among the cleanest motivating topologies for it. > > Either way, your topology deserves to be in the record the working group > is building this week: the chairs have asked for use cases and problem > statements before solutions, and agent-behind-gateway with a public-client > agent is arguably the most common deployment shape MCP has produced. I > would encourage writing it up exactly as you have here. > > Morgan > > On Wednesday, July 22nd, 2026 at 7:23 AM, Eric Leleu <eric.leleu= > [email protected]> wrote: > > Hi all, > > I'd like to raise a topology question about the ID-JAG draft > (draft-ietf-oauth-identity-assertion-authz-grant) that I expect to come up > often as agentic/MCP deployments grow, and I don't think the current text > resolves it from my understanding. > > Topology Description: > ---------------------------- > > - An AI coding agent (e.g. Claude Code) acts as an MCP Client. It is > registered at the enterprise IdP as a *public* client (native/CLI app, > PKCE, no client secret). > - The agent authenticates directly against the enterprise IdP. As per OIDC > Core, the resulting ID Token's `aud` is the agent's own client_id. In the > same flow the agent also obtains an access token whose audience/resource is > an MCP Gateway sitting in front of it. > - The MCP Gateway aggregates several upstream MCP servers. Each upstream > server is protected by its own Resource Authorization Server, and each of > those independently trusts the same enterprise IdP. > - Per ID-JAG, to reach a given upstream server the Gateway needs an access > token minted through the ID-JAG flow: Token Exchange at the IdP to mint an > ID-JAG (aud = upstream AS) and then execute JWT-Bearer redemption at that > AS. > > The conflict : > ----------------- > > Section 4.3.3 [1], "IdP Token Exchange Processing Rules", requires that > when the subject_token presented in the Token Exchange call is an identity > assertion (ID Token), "the IdP MUST validate the assertion and MUST > validate that the audience of the assertion (e.g. the aud claim of the ID > Token or SAML Audience) matches the client_id of the client authentication > of the request". In the Gateway topology above, this rule creates a dilemma > where neither party can execute the exchange: > > > 1. The agent is the audience of the ID Token, but the agent has no reason > to call Token Exchange itself — it doesn't know which upstream AS/audience > a given MCP tool call needs, and as a public client it's also not well > positioned to be trusted with that capability directly. As defined in the > draft "this specification SHOULD only be supported for confidential > clients." > 2. The Gateway is the party that actually needs the ID-JAG (it knows the > target upstream AS), and it is the Gateway that would authenticate the > Token Exchange call. But the ID Token's `aud` is the agent's client_id, not > the Gateway's. Per the mandatory audience check above, the IdP must reject > that exchange no matter how the ID Token reaches the Gateway (forwarded by > the agent or otherwise). > > > From my understanding, neither party in this agent-to-gateway architecture > can legally execute the ID-JAG exchange under the current specification. > > > Did I miss a mechanism already defined in the draft (or in > draft-ietf-oauth-identity-chaining) to handle this delegation/proxy pattern? > Is there ongoing work to address multi-hop or API Gateway patterns where > the identity assertion's audience differs from the calling proxy's > client_id? > > > Thanks, > Eric > > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant#name-processing-rules > > -- > > > > Eric LELEU > > Staff Software Engineer > > E [email protected] <[email protected]> > > Hold Nothing Back > <http://youtube.com/c/Graviteesource?sub_confirmation=1> > <https://www.linkedin.com/company/gravitee-io> > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
