Return-Path: X-Original-To: oauth@mail2.ietf.org Delivered-To: oauth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 66FE511CF1526 for ; Wed, 22 Jul 2026 22:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784784865; bh=wpITrLFRZu+fsVqcoNzGoY+ZPu7oRtVZTsBEOqR3czc=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=a+ol8EKbvpCrTrl/E1tQdRFME208nlYd8TEtti+rOnyBwHM50Z92PJfQflYgdauwZ cVl3vMT4oFB+usXHz/CtrA4AdQnDULA5qL+ONH6rtsra9lPsx13FDq8WkdXAoUzCjq JHgIv5Ebz6Fp9sU05OdIxyA1Fy/5yDPuIQx9ryMI= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=twilio.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNTAOlakARgn for ; Wed, 22 Jul 2026 22:34:22 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C88A911CF151F for ; Wed, 22 Jul 2026 22:34:21 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-39c953950dfso1475781fa.1 for ; Wed, 22 Jul 2026 22:34:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784784853; cv=none; d=google.com; s=arc-20260327; b=B7nKWoORRNk47ACDHoMOQKNeDWRQHaz50OEySKhCuxO+bfX+MLNcD5Ta0IVs4flFwl k4Gmd4fVXmoRd7IANSYRgnn5QMSZXNM9L22qFSyAzRs9yxL/9UYI8IuuI4HwDZkKBAAx 7sDT6Ue+UHaxn5LPO/n0Xrue5CaHr9YO5m4nMm+rcF/j/D3I3EQFg7eftvq4YrPm8zux YnNK9unrTHWMhdosfQZC52Uq9tmubqJMeeuEGAjdZ0nI08+F0JtCryM3m9lKCj0Ivn+0 Bvr49j8e+AujUrvPUvZjLOA/y1737v22NVGimMXDyD+DBtB0iYnUoTSOxP3wYkc91No8 Al9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=JUMA1IpXk43MT2fSGp7RVz4t+9GMN1r0K9p3AeKAD/g=; fh=UwO3gArrOaWz4sBc/heWkUjWWhP8NZF7FTtq297N+fE=; b=GdILcuKm/Jx7ZaJNNRhj3OIPCBJuQ0oHJGuzFgMg8Ff8LOmTijFWC+aB4kBxmPkWNC FEf5cn5jqCNVBSHKMHGOFQtKnanAFR8JdFRO1zWJrV9UnLmrDKGraKYwdBilQgcONZRV lTRTRGPGc99FiLeTrMs8HvJScqC/kEDeX315C7GXMVPEjBUjCb0CROTb+QAK2GjH/Pbq bzSrWJ7p/Kus5dBLZWTprThcJxRWZHXUpB/UXkmi/V6jDXlEtZn2mqev1uJSfT3WMlhe NhH1wuLjcpodl26oIyBuUcmvhqeZWAZpqtxTmXWZzrSKySM1JEfemcaZb9ZmeVlVGOjl G4rQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twilio.com; s=google1024; t=1784784853; x=1785389653; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=JUMA1IpXk43MT2fSGp7RVz4t+9GMN1r0K9p3AeKAD/g=; b=Q+io/XZvBCIr7bP1H63vduSypS5OMtA/s80g8CkOaIpzaWB77OF/pQ+8ErcY+EbFcP BWK7TwjoBawouH5eP4ssr+eMorsEGMHNyZ/Y1Zd0DJTD5Cs8qRoiqqBiBMsNugP8pbJw LesF2By0oRuSowg9D67m7ECiHQBYxkrDepKyA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784784853; x=1785389653; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=JUMA1IpXk43MT2fSGp7RVz4t+9GMN1r0K9p3AeKAD/g=; b=Af9KwLOodBEiw1ZYco4WrWMGs1xdC0eI6JTbZJA1UJmJ695y22fc0ckIbXCud55dEJ osZmfJBUwfpKmeozUbONeZXqgPamK1kmkBRT255pUD+fZcUa88Xn6gfHN5B1EYh5Ea3v XPe8s66ePMQbgPxoG29R46xRmI84SkyqqyFFcW6T6ZIAVy2xJUUYaQVgh8jnwvr4dY6n 5yGJmr/k0e8gB0d+adEwkrt0ZyNtZ3YXyyQUiKeHltGBI7Znvd8LJ0Bgvm18YwFpOnw6 EKSNqzu9THqIxGgZnsLrA595PzIHHncjJnYUHim/AasBJ5C/goTXbPTrBnoaB7jbpQ7d o8mQ== X-Forwarded-Encrypted: i=1; AHgh+RoOp7bYP/HE1xyqnj8MScron3LWJtue2BB1fz3/lRz3eDt5LYT5HLUTedR2sFmtf0jq7/w+EA==@ietf.org X-Gm-Message-State: AOJu0YwC5N1O+4KAGWVkXQ/OZW7PoD6qSsFwJXJcJ69d2d1V0B3YfmS6 q+TRxwNDkpyWA3hdeH8H+LqY5TL19Do42SFsZ5UF2cpZxvqguXHkNf5DMZ9YaVlmIrH2cAoDbpk FysbfqUefdSdKa3ZhPWkb/dHWN7U50sda4cDkQ4PPxA== X-Gm-Gg: AR+sD11P7dZw6MX3oJ0n0as/zt5F1dBFGv8v7dEjbph9TDFOMuxVE/u8C4XNk3RsYq+ zODT6YjEacjUob0sLA/7NCFwFU2iabtLwsSohiMwyRuY/mNfEmGuMmctrnQ9A1Xk/vlXKcQ8Lh8 oDKSH2R3+Lj/vrTyI/5BGp1h91lnBJFeoRSj6z7cgKx/GMcFlDxbiVV1K7XIQSVV66L4wAno33t X30SP2mAymXL1jYgDFcbB81fFWhvZX7jeP7LY2i2+I0w2I0MLgAMU41EEEhHruf X-Received: by 2002:a05:651c:2cb:b0:39e:f501:c816 with SMTP id 38308e7fff4ca-39f07e9eaa8mr2141791fa.24.1784784853317; Wed, 22 Jul 2026 22:34:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Max Gerber Date: Thu, 23 Jul 2026 07:34:02 +0200 X-Gm-Features: AUfX_mysQtpfUnuql6YIaaEzrxpE2XzTJXzmYrFG_FTFwyJjaSLhgYw93-WCZQU Message-ID: To: morganLR Content-Type: multipart/alternative; boundary="0000000000002ee91b0657409b44" Message-ID-Hash: NKXFDOYM2YWO5KKNIH6A5BYO4YYXWACY X-Message-ID-Hash: NKXFDOYM2YWO5KKNIH6A5BYO4YYXWACY X-MailFrom: mgerber@twilio.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Eric Leleu , Karl McGuinness , oauth X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_Question_on_ID-JAG_topology=3A_Public_Agent_+?= =?utf-8?q?_API_Gateway_/_MCP_Proxy_scenario?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002ee91b0657409b44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM morganLR 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 ther= e > 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 40graviteesource.com@dmarc.ietf.org> 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 =C3=A0 18:44, Karl McGuinness a > =C3=A9crit : > >> 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-at= tenuation/ >> ). This may not be relevant to your specific gateway deployment >> scenarios, but it is common in deployments where a gateway fronts existi= ng >> SaaS apps for example. >> >> I'm not super happy with the solution I arrived at ( >> https://mcguinness.github.io/draft-mcguinness-oauth-id-continuation-asse= rtion/draft-mcguinness-oauth-id-continuation-assertion.html >> and for this reason I haven't submitted it yet as an I-D because it stil= l >> 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 particu= lar >> 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=E2=80=AFAM morganLR > 40proton.me@dmarc.ietf.org> 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 a= n >>> 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 intend= s. >>> >>> 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 th= e >>> subject token's original audience while separately authorizing the acto= r as >>> a registered intermediary for that audience, resolves your topology wit= hout >>> new machinery. The cost is that the IdP must now hold policy about whic= h >>> 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-J= AG >>> per upstream AS, on the critical path. >>> >>> The other family carries the delegation as a verifiable artifact instea= d >>> 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 k= ey, >>> so the intermediary attenuates rather than exchanges, and no per-hop tr= ip >>> to the IdP exists. That property class (attenuation verifiable from the >>> artifact alone, no runtime callback to the issuing side, possession bou= nd >>> at each hop) is what R1, R3, and R4 in >>> draft-reece-wimse-cross-org-delegation describe, and gateway aggregatio= n is >>> among the cleanest motivating topologies for it. >>> >>> Either way, your topology deserves to be in the record the working grou= p >>> is building this week: the chairs have asked for use cases and problem >>> statements before solutions, and agent-behind-gateway with a public-cli= ent >>> 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 >> 40graviteesource.com@dmarc.ietf.org> 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 te= xt >>> 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 upstrea= m >>> 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 =3D upstream AS) and then execute JWT-Bearer redemp= tion >>> 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 ident= ity >>> 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 authenticat= ion >>> of the request". In the Gateway topology above, this rule creates a dil= emma >>> 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 =E2=80=94 it doesn't know which up= stream >>> AS/audience a given MCP tool call needs, and as a public client it's al= so >>> not well positioned to be trusted with that capability directly. As def= ined >>> in the draft "this specification SHOULD only be supported for confident= ial >>> clients." >>> 2. The Gateway is the party that actually needs the ID-JAG (it knows th= e >>> 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 rej= ect >>> 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 pat= tern? >>> Is there ongoing work to address multi-hop or API Gateway patterns wher= e >>> 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-asserti= on-authz-grant#name-processing-rules >>> >>> -- >>> >>> >>> >>> Eric LELEU >>> >>> Staff Software Engineer >>> >>> E eric.leleu@graviteesource.com >>> >>> Hold Nothing Back >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list -- oauth@ietf.org >>> To unsubscribe send an email to oauth-leave@ietf.org >>> >> > > -- > > > > Eric LELEU > > Staff Software Engineer / AM Teach Lead > > E eric.leleu@graviteesource.com > > Hold Nothing Back > > > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org > --0000000000002ee91b0657409b44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thinking out loud: One way to do this to= day is for the MCP Gateway to also act as a client to the IDP, requi= ring 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 Gate= way can use the ID Token to retrieve an ID-JAG for the upstream MCP AS. Thi= s ID-JAG will only identify the Gateway client, not the Agent itself. This = would make the Gateway responsible for access control decisions & audit= ing, and it cuts off the IDP from observing per-Agent behavior - which undo= es 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 `a= ctor_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 Agen= t identity + Gateway identity within the ID-JAG). Actor tokens are delibera= tely 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=E2=80=AFAM morganLR <mo= rganLR=3D40= proton.me@dmarc.ietf.org> wrote:
Eric,

Good qu= estion, it is my understanding that the two paths you named do different jo= bs, 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: doe= s ID-JAG address this topology, or is it out of scope by design?=C2=A0

2. The use-case record, for the broader p= oint. The chairs have been clear that use cases and requirements come befor= e mechanism selection, and there is an active collection effort (draft-chen= -oauth-agent-authz-use-cases is the current gathering point).=C2=A0<= /div>

3. If you want it durable under your own nam= e, a short individual problem-statement I-D is always an option.

Happy to look over the issue text before you fi= le it if that's useful.

Best,
Morgan
On Wednesday, July 22nd, 2026 at 2:12 PM, Eric Leleu <eric.leleu= =3D40graviteesource.com@dmarc.ietf.org> 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 topo= logy 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 ope= n 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 agai= n,
Eric

Le mer. 22 juil. 2026 =C3=A0 18:44, Karl McGuinness= <me@karlmcguinness.com> a =C3=A9crit :
<= /div>
Extending ID-JAG to support public clients is an open topic for discussio= n. I encourage you to read these issues and chime in with additional use c= ases, concerns, or feedback


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 ha= ve access to the original identity assertion to obtain a new ID-JAG. I've been exploring this scenar= io 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 (<= a href=3D"https://notes.karlmcguinness.com/notes/re-subjecting-is-a-mint-no= t-an-attenuation/" rel=3D"noreferrer nofollow noopener" style=3D"word-break= :break-word" target=3D"_blank">https://notes.karlmcguinness.com/notes/re-su= bjecting-is-a-mint-not-an-attenuation/). This may not be relevant to your specific gateway deployme= nt scenarios, but it is common in deployments where a gateway fronts existi= ng SaaS apps for example.

I'm not super happy with the solution = I arrived at (h= ttps://mcguinness.github.io/draft-mcguinness-oauth-id-continuation-assertio= n/draft-mcguinness-oauth-id-continuation-assertion.html and for this re= ason I haven't submitted it yet as an I-D because it still needs worksh= opping. 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 sol= ution isn't pretty.

For scenarios that don't need re-subjec= ting then an attentuation based soluton may be attractive but that it outsi= de the scope of the ID-JAG profile.

-Karl




On Wed, Jul 22= , 2026 at 8:58=E2=80=AFAM morganLR <morganLR=3D40proton.me@dmarc.ietf.org> wrote:

Eric,

The dilemma is real and I do not think you missed a mech= anism. It is worth naming why it arises structurally: an identity assertion= is audience-locked to the party it was issued to, and delegation through a= n intermediary requires either re-minting at the issuer or a way for the in= termediary's participation to be first-class in the exchange. Section 4= .3.3 as written admits neither, so every gateway hop reproduces your dilemm= a.

Two resolution families exist, and the draft c= ould name which it intends.

Within the current model, RF= C 8693 already has the missing piece: the actor_token. A composite exchange= where the gateway authenticates as itself, presents the agent's assert= ion as subject_token and its own credential as actor_token, and the IdP app= lies the audience check to the subject token's original audience while = separately authorizing the actor as a registered intermediary for that audi= ence, resolves your topology without new machinery. The cost is that the Id= P 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: t= he 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 ga= teway in a form the upstream can verify directly against the original issue= r's key, so the intermediary attenuates rather than exchanges, and no p= er-hop trip to the IdP exists. That property class (attenuation verifiable = from the artifact alone, no runtime callback to the issuing side, possessio= n 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 motivati= ng topologies for it.

Either way, your topology deserves= to be in the record the working group is building this week: the chairs ha= ve asked for use cases and problem statements before solutions, and agent-b= ehind-gateway with a public-client agent is arguably the most common deploy= ment 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= =3D40gra= viteesource.com@dmarc.ietf.org> wrote:
Hi all,

I'd like to raise a to= pology question about the ID-JAG draft (draft-ietf-oauth-identity-assertion= -authz-grant) that I expect to come up often as agentic/MCP deployments gro= w, 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 clien= t secret).
- The agent authenticates directly against the enterprise IdP= . As per OIDC Core, the resulting ID Token's `aud` is the agent's o= wn 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 pr= otected by its own Resource Authorization Server, and each of those indepen= dently trusts the same enterprise IdP.
- Per ID-JAG, to reach a given u= pstream server the Gateway needs an access token minted through the ID-JAG = flow: Token Exchange at the IdP to mint an ID-JAG (aud =3D upstream AS) and= then execute JWT-Bearer redemption at that AS.

The conflict :
-= ----------------

Section 4.3.3 [1], "IdP Token Exchange Process= ing Rules", requires that when the subject_token presented in the Toke= n Exchange call is an identity assertion (ID Token), "the IdP MUST val= idate 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 o= f the client authentication of the request". In the Gateway topology = above, this rule creates a dilemma where neither party can execute the exch= ange:


1. The agent is the audience of the ID Token, but the agen= t has no reason to call Token Exchange itself =E2=80=94 it doesn't know= which upstream AS/audience a given MCP tool call needs, and as a public cl= ient it's also not well positioned to be trusted with that capability d= irectly. As defined in the draft "this specification SHOULD only be su= pported 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&= #39;s `aud` is the agent's client_id, not the Gateway's. Per the ma= ndatory audience check above, the IdP must reject that exchange no matter h= ow the ID Token reaches the Gateway (forwarded by the agent or otherwise).<= br>

From my understanding, neither party in this agent-to-gateway ar= chitecture can legally execute the ID-JAG exchange under the current specif= ication.


Did I miss a mechanism already defined in the draft (or= in draft-ietf-oauth-identity-chaining) to handle this delegation/proxy pat= tern?
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<= /a>

--

_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org


--



Eric LELEU

Staff Software Engineer / AM Teach Lead

E


Hold Nothing Back

<= span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(34,34,3= 4);background-color:transparent;font-weight:700;vertical-align:baseline"> =

_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
--0000000000002ee91b0657409b44--