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
<[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
>> <[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
>>> <[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]](mailto:[email protected])
>>>>
>>>> Hold Nothing Back
>>>>
>>>> http://youtube.com/c/Graviteesource?sub_confirmation=1https://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]](mailto:[email protected])
>
> Hold Nothing Back
>
> http://youtube.com/c/Graviteesource?sub_confirmation=1https://www.linkedin.com/company/gravitee-io
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
