Morgan, Karl, Thank you both for the detailed and thoughtful responses. I'll block out time to properly go through the references you both pointed to.
Morgan, one practical question on process: you mentioned this topology deserves to be in the record the working group is building this week. I'm not familiar with the actual procedure for that. Should I open a GitHub issue against the ID-JAG repo, or write it up as a separate use-case/problem statement? If the latter, where should that go? Happy to follow whichever path is expected. Thanks again, Eric Le mer. 22 juil. 2026 à 18:44, Karl McGuinness <[email protected]> a écrit : > 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] >> > -- Eric LELEU Staff Software Engineer / AM Teach Lead 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]
