Hi all, First time posting here, so please take this as a question rather than a proposal. I have been following this thread along with issues #114 and #115, and there is one framing that helped me understand the disagreement. I would like to know whether it holds up for people who know this material better than I do.
The framing is about responsibility: who decides what scope is needed upstream, and who decides whether that scope can be issued. In the simple case (user, app, upstream service) both sit with the party the user logged into, which is why the audience check in 4.3.3 is unremarkable. Add a gateway and they come apart, and I think that is the choice underneath the mechanism debate. Either the app keeps deciding scope, in which case the gateway is not really the permission boundary that deploying a gateway usually implies, or the gateway decides scope and brokers across trust boundaries, in which case we need another way to carry the user and app identity. Both look like valid architectures to me. Two things I could not work out from the discussion so far. First, where the scope comes from in the brokered shape. The policy evaluation is described as being over (user, app, gateway, audience, scope), and Jeff's point that only the gateway knows the backend resource expectations suggests the gateway is the one naming the scope. If so, the IdP is deciding on a scope the app never requested, against consent the user gave the app at login. zekth mentioned consent as something the sketch surfaces, and I would like to understand how that is meant to work. Second, Eric's original topology had the agent holding an access token audienced to the gateway, which is an IdP decision that this app may use this gateway. The shape the issue converged on forwards the ID Token instead, which carries who the user is but not that grant. Is dropping the inbound authorization decision deliberate, or just not the part under discussion? From where I sit it looks like the thing that would make the gateway an enforcement point rather than only an identity consumer. One smaller thing. Both shapes are framed around provisioned, enterprise-controlled clients, and Kieran noted the guarantees stop being free once hops span organizations. Most of what I see in practice is a gateway from one vendor in front of agents from another. I am curious what the intended answer is there, or whether that is deliberately out of scope for now. If the cross-client delegation work is becoming its own I-D, saying which of the two allocations it assumes might be worth doing early, since a lot follows from it. Happy to be told I have this wrong. -- Barak Shelef Head of Technology, CTO Office Oasis Security On Tue, Jul 28, 2026 at 9:10 AM Lombardo, Jeff <jeffsec= [email protected]> wrote: > The two options described fits well other side of the scenario: > > On top of what was expressed, URL elicitation is a clear path for specific > claims [RAR] and scopes acquisition through a new minted token before > aiming for the JAG based on backend resource expectations that only the > Gateway can know. > > Two side notes on this thread: > > 1. the IDP definitively need to keep track of all those exchanges and > perform some decisioning on if a / the next minting needs to happen. One > thing that appeared clearly last week is that IDPs will need to be equipped > with policy based logic to support them in the task. Such stance will > support any auditing, governance, and threat adaptation, especially if the > Gateway is a 3rd party as the IDP could not trust it into the global > decisioning. > > 2. There are a lot of work on the formatting of the act claim structure > especially for long chain. I am not sure we finally solved this one. > > > > *Jeff* > > > > *From:* Kieran Sweeney <[email protected]> > *Sent:* July 28, 2026 6:20 AM > *To:* Karl McGuinness <[email protected]> > *Cc:* morganLR <[email protected]>; oauth < > [email protected]>; Eric Leleu <eric.leleu= > [email protected]> > *Subject:* [EXT] [OAUTH-WG] Re: Question on ID-JAG topology: Public Agent > + API Gateway / MCP Proxy scenario > > > > *CAUTION*: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > *AVERTISSEMENT*: Ce courrier électronique provient d’un expéditeur > externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous > ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas > certain que le contenu ne présente aucun risque. > > > > Karl, > > A few points on the ICA draft, aimed at where it may need tightening. The > direction is right; these are the parts I would want nailed down before it > is implementable. > > 1. The per-boundary round trip is on the interactive path. The draft > prices the chain in round trips but does not say the continuation > resolution sits inside a user-visible agent tool call. That is where > implementers will cache the resolution to cut latency, and a cached > resolution is where the cross-audience linkability the design prevents > comes back. The draft should state that continuation resolution is > per-invocation and specify what an implementation may and may not cache > across audiences. > 2. Specify the public-client entry point. The draft assumes mutually > authenticated intermediates at the Chain Authority boundary, but the common > origin is a public client: a CLI agent with a locally generated key and no > confidential credential. Sender-constraint (cnf) is weakest exactly there. > The draft could say how the initial cnf enters the chain when the origin is > a public client, since that is the entry point most deployments will have. > 3. State whether the Chain Authority is a hard dependency. It is a > stateful, per-domain component on the request path. The draft could say > whether it is mandatory, and if it can be absent or unavailable, what the > chain's guarantees degrade to without it. As written, the security > properties are defined only for the full deployment, not the partial ones > that will get run. > 4. Lead with revocation; it is the load-bearing property. Resolving > each continuation against control-plane state at every boundary is what > makes an otherwise mint-time chain enforceable: each hop becomes a fresh > policy point instead of trusting an artifact minted before a revocation. > Concretely, the draft should state whether revoking authority at one hop > invalidates authority already derived downstream, and over what window. > That guarantee is what the round trip is buying, and it is worth making > explicit rather than leaving as a consequence. > > The audience-check thread (#114) has been converging on the same chain > semantics from the mint side, so the two are worth reconciling. > > > > Best, > > Kieran > > > > On Sun, Jul 26, 2026 at 4:04 PM Eric Leleu <eric.leleu= > [email protected]> wrote: > > Hi Max, Morgan, and Karl, > > Thank you all for the valuable feedback. > > Following Morgan's suggestion, I’ve opened two issues regarding this use > case: > > - On the oauth-identity-assertion-authz-grant GitHub repository [1] > - As a proposed use case in draft-chen-oauth-agent-authz-use-cases [2] > > Karl*, *I reviewed your *Identity Continuation Assertion* proposal, and > it addresses this issue nicely. I particularly like that it keeps the ID > Token on the client side rather than forwarding it to an unintended > audience. > > Max*,* Your proposal around the elicitation flow seems to solve the > immediate issue of granting access to upstream servers. However, as Morgan > pointed out, we lose visibility into the delegation chain, which isn't > ideal (even if it might be the best available workaround given the current > state of the draft). > > Best regards, > > [1] > https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/114 > > [2] https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/16 > > > > Le ven. 24 juil. 2026 à 21:02, morganLR <morganLR= > [email protected]> a écrit : > > Max, > > > > This is a useful decomposition, and I think your own parenthetical > identifies the crux: the workaround makes the gateway the subject, and > everything upstream of it sees only the gateway. That is not an > implementation wrinkle, it is the general behavior of re-subjecting > intermediaries: each mediation hop that acquires authority under its own > identity collapses the chain behind it, and whatever the deployment needed > the chain for (per-agent policy, audit attribution, differential > revocation) has to be reconstructed some other way. > > > > The actor_token idea does help, but it is worth being precise about what > it buys and what it costs. It records one hop: agent plus gateway, bound at > mint time. Generalized to deeper topologies (agent behind agent behind > gateway, which is the ordinary MCP composition case), it becomes stacked > act semantics minted by the IdP per hop, which means the IdP is the > recorder of the chain and every extension of the chain is a round-trip to > it. That is a coherent architecture, and for the fullest articulation of it > I would point at Karl's Identity Continuation Assertion note, which works > out the caller-pushed, control-plane-resident version of exactly this > direction, including its revocation story. The trade is then explicit: > chain state lives at the control plane, per-agent visibility is restored to > the IdP, and the chain's length is priced in round-trips. > > > > One assumption in the scenario deserves flagging, because it is where the > hard version of the problem lives: the construction works because the > agent, the gateway, and the upstream all sit in one IdP's orbit, so the > actor_token is validatable by its own issuer. When the gateway and the > agent belong to different organizations (the multi-vendor gateway case, > which the DMSC BoF decks this week treated as the normal deployment), > validating that actor_token is itself the cross-domain trust-establishment > question, and we are back at the cold-start gap the use-cases draft now > names in UC5. > > > > Which is my main suggestion: this thread has produced better deployment > evidence for that gap than anything currently in the draft. Meiling has > opened issues #17 (UC5 alignment) and #18 (the cross-organizational > companion case) on the use-cases repository; the gateway-collapse > observation and the one-orbit assumption both belong there as recorded > evidence, and I would encourage you to add them. The mechanism questions > will sort themselves out per draft; the requirements record is what seems > to be collecting this year > > > > Morgan > > On Thursday, July 23rd, 2026 at 12:34 AM, Max Gerber <mgerber= > [email protected]> wrote: > > Thinking out loud: One way to do this today is for the MCP Gateway to > *also* act as a client to the IDP, requiring the end user to log in to > both the Gateway and the Agent. This can be done with URL Elicitation in > the MCP space, or if the Gateway runs its own OAuth AS as a shim. The Agent > gets a regular access token, and the Gateway gets an ID Token with the > Gateway client as the audience. > > > > When the Agent makes requests to the Gateway, the Gateway can use the ID > Token to retrieve an ID-JAG for the upstream MCP AS. This ID-JAG will only > identify the Gateway client, not the Agent itself. This would make the > Gateway responsible for access control decisions & auditing, and it cuts > off the IDP from observing per-Agent behavior - which undoes a lot of the > benefits of ID-JAG in the first place. > > > > Would having the Gateway pass in the Agent's access token as an > `actor_token` in the token exchange request to the IDP help here? That > would give the IDP a mechanism to identify the Agent (and also bind both > the Agent identity + Gateway identity within the ID-JAG). Actor tokens are > deliberately out of scope of the ID-JAG spec, but they could be defined in > a future profile. > > > > On Thu, Jul 23, 2026 at 3:58 AM morganLR <morganLR= > [email protected]> wrote: > > Eric, > > > > Good question, it is my understanding that the two paths you named do > different jobs, so I'd suggest both, in this order given the timing this > week. > > > > 1. GitHub issue against the ID-JAG repo, today if you can. That's the > right vehicle for the narrow question: does ID-JAG address this topology, > or is it out of scope by design? > > > > 2. The use-case record, for the broader point. The chairs have been clear > that use cases and requirements come before mechanism selection, and there > is an active collection effort (draft-chen-oauth-agent-authz-use-cases is > the current gathering point). > > > > 3. If you want it durable under your own name, a short individual > problem-statement I-D is always an option. > > > > Happy to look over the issue text before you file it if that's useful. > > > > Best, > > Morgan > > On Wednesday, July 22nd, 2026 at 2:12 PM, Eric Leleu <eric.leleu= > [email protected]> wrote: > > 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] > > > > > > > -- > > > > > > > *Eric LELEU * > > Staff Software Engineer / AM Tech 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] > > > > > -- > > Kieran Sweeney > 310 - 330 - 6458 > > _______________________________________________ > 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]
