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 3CA6D120AA3E0 for ; Wed, 29 Jul 2026 11:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785348401; bh=zQCCdY0wM9L7o9giQxjX11xXsQak1oS51qMWfV1eEfc=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=MNUzilzbzE34s8TiCz3NgANKYxWcBWYueGF6z4Z1YtCNsehrvvOX3NHoBe0YHyXNV EzOdg1SgmsayNpRHgVzLxcEtc180RaB6/eSTcvhPYmgOk5IGNSnG9apXavg9MeFts6 SOvJlrAtnhm1KepAV3y2KtKk0Wz892hLEGNyEm2Y= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=graviteesource.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 UKBCeyTze9sr for ; Wed, 29 Jul 2026 11:06:38 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 02B37120AA0E8 for ; Wed, 29 Jul 2026 11:06:31 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-69c5fda04a8so2057995a12.1 for ; Wed, 29 Jul 2026 11:06:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785348391; cv=none; d=google.com; s=arc-20260327; b=ZSB5liM5w1S0oOPy9bPf3D6M/Xl5w3tTA2yyGhWWB0foeVSiCVfw9X723qLl5/M7ED QI8u6S1y+2rlkJksqqbhPtfjf3Clx80VCwcnMv9o/ehCzNZwITqF0g+4RHc0bZD5BVQz wzxlxK+NOoTLxAhWbfiZAGKiHiteuExezn/mlsyftpdEzX2xi1Wl5F5asE5aZoGwidST KIH6ggxOsZ8IQ8uCDgbrvch7isZlj+eOkKx972aMYmRNwuOxwZ5GKwwrSadhLs6IwdRL 7lyJixLww/qB3hQU/j/eyO//NrVbrXU5Mv2NG8fBGSUytATBjkFvui0W+84Shkm+fTKh pA4w== 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=eF+OClTfOPWs9TEIUOIQEBKNfug+a6+uA8oWmHP8jfI=; fh=Rr4N03xU4giBR8x0MCrbTNnLl1GPuxKqGwC/gcJV3TU=; b=bXb/APxgzc2Jvr+mSFNaonNTIWz8AldvbkXyiXs/no3mrPUoQMtDoOo2nU9I7ZIrbW 6CW60R7oPAnLYD97a7RubBkrdezYWcapY4RJqoafo8J82KaVNw4vG4aeJS17VdgWZxiw JeHuhyoArRW5hEIxbMIytG2iA9LwmY68vpc72JmFnRdb9LNL1byvT2qECyJga60sogqh chP85grYp66ZTp3mig4uhWZ3IjAJYZpQidZzWrA/jQ5Q8KWs7x0hLpt9MBVmUoQZT1tg To8ysuu3hJH6geawzoEkI7tH1t+F+h4CoUhFrPkS7vU43bvUx0CljcGLUrNapJ5uWvv2 Gvqg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=graviteesource.com; s=google; t=1785348391; x=1785953191; 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=eF+OClTfOPWs9TEIUOIQEBKNfug+a6+uA8oWmHP8jfI=; b=BMlQhc74FJPQ9U6IBi3Wc46FLX7F2Ek3vvFKPvUWq+9SDQmo0wKs86NH1ap01xdgE8 0WK2kcCvkCNKtCwjCWvDHd4eirpjrpqi5Zj0P9cZLm6j2XT+Tyaudm+Y2Iztpp6+Ksez RatePFSvSfFUuXxyD9xBfOfNneIXXlTh5rJlmeFOHO7YvQJhhg9qGNteoP4AqN/gE1no Ur4i93zrPjFBf3cnFncWooZiu9z5FDM+1GLKhLqox0UcVP0o2Z1h3V3u0NHDw6RK7Gkw CJuHxED3wLOHxk7moV29bfqZnp1V6FnSDvsvnIF4pudkKQ0xxbWau9xUpP0lP8xTuPN9 6UnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785348391; x=1785953191; 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=eF+OClTfOPWs9TEIUOIQEBKNfug+a6+uA8oWmHP8jfI=; b=EcTss7EzL/Gm2y2915TXK+iroW/SMKjHY/Y+SAc4M0HRR0+7GWvYGNZ+o/X4SGfeKe YDYsOQIx6/XRWf8oCgL9IBsEtaOKg6q0Qv4+UZ+2C03Zzr1qEsUsgmSoOONmyORhaX62 eZgzRYQET2LIxP566TAvibdBwB3Pf+8V8XOer9+9zIDuUuELSy/IUO2NfPfdR7JAh2bp gHbTaYUCqb+BbJBtujDV5CrRFwqdXeRQSahKBsXPLcYQ6VdHDdbfT97BTqW6ACxd8zGb vI9VF3Ct+Vk8GU08CUKLI3qQQXprRO/kQXz8KBNe6D2qImp7x6YUL9AnWCWHEjQ5WEoU ChAQ== X-Forwarded-Encrypted: i=1; AHgh+RratS+ZSmXNMbQcIFjtIc7L7RkSrM2IE4d8tOfbsHkE7J2v+bn7MmPdaW9XQWUwm+mWE7sZeQ==@ietf.org X-Gm-Message-State: AOJu0Yz17jy7yi9WCDUeZjXX9mdIBOVSrbo/25LjI/wNWVakHm/oRfN1 vqfOBjdW02B/QS9/qNAONh17OjROMUoLJF4QYjZf4MApcVKmw6+wl/cfLgaq5DUgfT8VsSOi3G4 v0zvhTVFmr3uInsJE1j4mBEbB6dsMet9T/daUQkAmWA== X-Gm-Gg: AR+sD11EmBzfnD677YbKhAE9ENAMgePk4PySUIPbc8RsdgjRA1diErfmZ3RXiFrVDgw UhOlXkTAkoU+DTG0yAyWpIKnFRnvr2c95wVoOnZB0STI9WXflRdh2CYulmxCZ/dTZt7XVCYOKG9 cleubsjpuwTh5VOJmBYU4pRlgl3vTqHLXH4rtrXnddRCg01sz8L3E0TY4CEhM5yAyMy9T/ogmze fXfl3PstXJBGXH9keaWAVM7puxerHOvPcYutx7K10a6AV85zuY4jhTuj8RrxeJ5HSurWmOi4xSk ULpU7PKZ5yE4fYBe3JEX8CFLcSoHRxKgOsb1umgQVkvKgE5IAfbqUCfh0GhjA7E+3g+dkgKP436 X X-Received: by 2002:a05:6402:5505:b0:698:bbe:9c8 with SMTP id 4fb4d7f45d1cf-6a034a25e6amr3965592a12.15.1785348390487; Wed, 29 Jul 2026 11:06:30 -0700 (PDT) MIME-Version: 1.0 References: <0mIKidCQfLI40qLXGigH-qqaLN-BA7nIpOL0P_ELkjlSt3tk5_l_bfkj8lVsXFGfxZUg-2ScX4HMkK1nrduybXhtOHRjAbTFopZGKp5VQ3o=@proton.me> In-Reply-To: From: Eric Leleu Date: Wed, 29 Jul 2026 20:06:18 +0200 X-Gm-Features: AUfX_myoHknxEY-HJDuQq-ZD6SK61T2tqDnOGdShRt4Bg7j0gblxfMHXLMHxFiQ Message-ID: To: Karl McGuinness Content-Type: multipart/alternative; boundary="0000000000009d9e340657c3d0fa" Message-ID-Hash: ABNSPQTBSWCICMBJD6U47ASDLESB35NU X-Message-ID-Hash: ABNSPQTBSWCICMBJD6U47ASDLESB35NU X-MailFrom: eric.leleu@graviteesource.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: Barak Shelef , Kieran Sweeney , morganLR , 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: --0000000000009d9e340657c3d0fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Barak, Karl =E2=80=94 thank you both. Barak, to answer your question directly: no, dropping the inbound authorization decision is not what I am proposing. In my topology the client sees the MCP proxy as the only MCP server; the upstream servers are hidden behind it. When the client authenticates to reach the proxy, the scopes the user approves are the ones the proxy defines and exposes =E2=80= =94 they are not the scopes required by the upstream MCP servers, which are protected by other Authorization Servers. As Karl noted, the scopes granted at the token exchange performed by the MCP gateway/proxy to interact with the upstream MCP servers are based on security policies defined at the IdP, as described in ID-JAG. The access token carries the incoming authorization decision, the identity proof carries the subject; the proxy needs both. That is why I would keep an access token as the authorization element at the MCP proxy: per the MCP protocol, the proxy is the instance the client actually performed authentication/authorization for. The security of this delegation scenario rests largely on the proxy being able to correlate the incoming credential with the identity assertion =E2=80=94 if it authorizes the call and that correlation holds, it can then initiate the delegation request on the basis of the identity proof, conveyed over a channel that remains to be defined. Passing the ID Token as an identity proof (not as an authorization element) to the MCP proxy works for me. The CCDR helps to perform that correlation and to track the delegation, thanks to the actor_token and the act claim. Since the CCDR establishes that the Delegate is authorized to act for the Initiator =E2=80=94 whose client_id is the aud of the ID Token =E2=80=94 th= e audience validation constraint of the ID-JAG draft can be relaxed: literal audience matching is replaced by verification of that relationship. Deciding whether or not to issue the ID-JAG remains the IdP's responsibility, through the security policies its administrator defines in the enterprise context. The MCP proxy is the only instance with visibility over the upstream servers' scopes, so it is its responsibility to make the appropriate request to the IdP to obtain those scopes in the ID-JAG token, which then allows it to request them from the Resource Authorization Server= . One of the motivations for this policy-based approval is to limit human interactions to approve actions that can be approved automatically in an enterprise context, where the resources belong to the organization and where an entitlement/permission system is already in place to control access based on the employee's identity. Best regards, Eric Le mer. 29 juil. 2026 =C3=A0 15:31, Karl McGuinness = a =C3=A9crit : > Barak, > > Thanks for the framing. Answering the four points. > > *Who decides scope in the brokered shape.* > > D-JAG's consent model isn't consumer OAuth's. ID-JAG moves the consent > decision to the admin/IdP layer by design. Users don't consent to each > cross-app grant. Enterprise admins configure which cross-app access is > permitted, and the IdP enforces at ID-JAG issuance time. > > The brokered shape inherits this. Gateway-decides-scope isn't a new > consent question. It's the same enterprise-managed model with one more > admin-configured party (the broker) in the chain: user consented to > enterprise SSO, admin configured the CCDR between agent and broker, IdP > enforces both at Token Exchange time. > > Bolting consumer-style per-scope consent onto the brokered shape is a > legitimate design point but it moves away from the enterprise-managed mod= el > ID-JAG was built for. Any I-D that adds it is really adding a new consent > layer on top of ID-JAG. > > *Access token vs. ID Token as the inbound artifact.* > > You're picking up something real. Eric's original topology in #114 > > carried the inbound authorization decision (this app may use this > gateway) via an access token audienced to the gateway. The current > sketches > rep= lace > that with the administered CCDR. > > Both are admin/IdP-controlled but distribute the decision differently: > access-token-audienced-to-gateway is per-authorization (minted at auth > time), the administered CCDR is per-deployment (configured at the IdP). > > The Enterprise Broker deployment pattern brings per-invocation binding > back in its Authenticated Handoff section > , > where the broker validates a Broker-audience access token accompanying th= e > ID Token. That composes with the CCDR rather than replacing it. The base > Cross-Client Delegation profile doesn't require it. The deployment patter= n > strongly recommends it. Worth being more explicit in the base profile abo= ut > this being a deployment-selectable enforcement point. > > *Cross-organizational gateway.* > > Deliberately out of scope for both sketches. The current profile relies o= n > the IdP administering both endpoints of the CCDR, which works within an > organization but not across. > > Meiling Chen's use-cases work (#17 > and > #18 = ) > is tracking this. draft-reece-wimse-cross-org-delegation > > is approaching the same problem from the WIMSE side. My take is it needs > its own mechanism (federation, attestation, or a Chain Authority) that > composes with cross-client delegation but doesn't fit inside it. > > *Explicitly stating the allocation.* > > Fully agree. The current sketches assume gateway-decides-scope with > administered trust as the consent basis (consistent with ID-JAG's > enterprise-managed model). Consumer-style user-consent-per-scope is an > explicit non-goal. That belongs in the Applicability Statement of any I-D > that comes out of this. > > Thanks again for the framing. > > -Karl > > On Wed, Jul 29, 2026 at 5:55=E2=80=AFAM Barak Shelef wrote: > >> 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 fo= r >> 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, upstrea= m >> 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 tha= t >> 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 whic= h >> of the two allocations it >> assumes might be worth doing early, since a lot follows from it. Happy t= o >> be told I have this wrong. >> >> -- >> Barak Shelef >> Head of Technology, CTO Office >> Oasis Security >> >> On Tue, Jul 28, 2026 at 9:10=E2=80=AFAM Lombardo, Jeff > 40amazon.com@dmarc.ietf.org> 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 o= nly >>> 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. On= e >>> thing that appeared clearly last week is that IDPs will need to be equi= pped >>> 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 >>> *Sent:* July 28, 2026 6:20 AM >>> *To:* Karl McGuinness >>> *Cc:* morganLR ; oauth < >>> oauth@ietf.org>; Eric Leleu >> 40graviteesource.com@dmarc.ietf.org> >>> *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 a= nd >>> know the content is safe. >>> >>> >>> >>> *AVERTISSEMENT*: Ce courrier =C3=A9lectronique provient d=E2=80=99un ex= p=C3=A9diteur >>> externe. Ne cliquez sur aucun lien et n=E2=80=99ouvrez aucune pi=C3=A8c= e jointe si vous >>> ne pouvez pas confirmer l=E2=80=99identit=C3=A9 de l=E2=80=99exp=C3=A9d= iteur et si vous n=E2=80=99=C3=AAtes pas >>> certain que le contenu ne pr=C3=A9sente 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 be= fore >>> 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 preven= ts >>> comes back. The draft should state that continuation resolution is >>> per-invocation and specify what an implementation may and may not ca= che >>> 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 or= igin 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, wha= t 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 w= hat >>> makes an otherwise mint-time chain enforceable: each hop becomes a f= resh >>> policy point instead of trusting an artifact minted before a revocat= ion. >>> Concretely, the draft should state whether revoking authority at one= hop >>> invalidates authority already derived downstream, and over what wind= ow. >>> That guarantee is what the round trip is buying, and it is worth mak= ing >>> 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=E2=80=AFPM Eric Leleu >> 40graviteesource.com@dmarc.ietf.org> wrote: >>> >>> Hi Max, Morgan, and Karl, >>> >>> Thank you all for the valuable feedback. >>> >>> Following Morgan's suggestion, I=E2=80=99ve 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 I= D >>> 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 Mor= gan >>> pointed out, we lose visibility into the delegation chain, which isn't >>> ideal (even if it might be the best available workaround given the curr= ent >>> 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 =C3=A0 21:02, morganLR >> 40proton.me@dmarc.ietf.org> a =C3=A9crit : >>> >>> 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 ow= n >>> identity collapses the chain behind it, and whatever the deployment nee= ded >>> 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 wha= t >>> it buys and what it costs. It records one hop: agent plus gateway, boun= d at >>> mint time. Generalized to deeper topologies (agent behind agent behind >>> gateway, which is the ordinary MCP composition case), it becomes stacke= d >>> 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 o= f it >>> I would point at Karl's Identity Continuation Assertion note, which wor= ks >>> 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 restore= d 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 t= he >>> 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-establishm= ent >>> 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 question= s >>> will sort themselves out per draft; the requirements record is what see= ms >>> to be collecting this year >>> >>> >>> >>> Morgan >>> >>> On Thursday, July 23rd, 2026 at 12:34 AM, Max Gerber >> 40twilio.com@dmarc.ietf.org> 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 i= n >>> the MCP space, or if the Gateway runs its own OAuth AS as a shim. The A= gent >>> 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 I= D >>> Token to retrieve an ID-JAG for the upstream MCP AS. This ID-JAG will o= nly >>> identify the Gateway client, not the Agent itself. This would make the >>> Gateway responsible for access control decisions & auditing, and it cut= s >>> off the IDP from observing per-Agent behavior - which undoes a lot of t= he >>> 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 bot= h >>> 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 >> 40proton.me@dmarc.ietf.org> 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 thi= s >>> 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 topolog= y, >>> 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 >> 40graviteesource.com@dmarc.ietf.org> wrote: >>> >>> Morgan, Karl, >>> >>> Thank you both for the detailed and thoughtful responses. I'll block ou= t >>> 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 n= o >>> 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-a= ttenuation/). >>> This may not be relevant to your specific gateway deployment scenarios,= but >>> it is common in deployments where a gateway fronts existing SaaS apps f= or >>> example. >>> >>> I'm not super happy with the solution I arrived at ( >>> https://mcguinness.github.io/draft-mcguinness-oauth-id-continuation-ass= ertion/draft-mcguinness-oauth-id-continuation-assertion.html >>> and for this reason I haven't submitted it yet as an I-D because it sti= ll >>> 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 partic= ular >>> 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 >>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> >>> >>> >>> *Eric LELEU * >>> >>> Staff Software Engineer / AM Tech 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 >>> >>> >>> >>> >>> -- >>> >>> Kieran Sweeney >>> 310 - 330 - 6458 >>> >>> _______________________________________________ >>> OAuth mailing list -- oauth@ietf.org >>> To unsubscribe send an email to oauth-leave@ietf.org >>> >> --=20 Eric LELEU Staff Software Engineer / AM Tech Lead E eric.leleu@graviteesource.com Hold Nothing Back --0000000000009d9e340657c3d0fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Barak, Karl =E2=80=94 thank you bo= th.

Barak, to answer your question directly: no, droppi= ng the inbound authorization decision is not what I am proposing. In my top= ology the client sees the MCP proxy as the only MCP server; the upstream se= rvers are hidden behind it. When the client authenticates to reach the prox= y, the scopes the user approves are the ones the proxy defines and exposes = =E2=80=94 they are not the scopes required by the upstream MCP servers, whi= ch are protected by other Authorization Servers.

As Karl noted, the scopes granted at the token exch= ange performed by the MCP gateway/proxy to interact with the upstream MCP s= ervers are based on security policies defined at the IdP, as described in I= D-JAG.

The access token carries the incoming authorization= decision, the identity proof carries the subject; the proxy needs both. Th= at is why I would keep an access token as the authorization element at the = MCP proxy: per the MCP protocol, the proxy is the instance the client actua= lly performed authentication/authorization for. The security of this delega= tion scenario rests largely on the proxy being able to correlate the incomi= ng credential with the identity assertion =E2=80=94 if it authorizes the ca= ll and that correlation holds, it can then initiate the delegation request = on the basis of the identity proof, conveyed over a channel that remains to= be defined.

Passing the ID Token as an identity proof (not as a= n authorization element) to the MCP proxy works for me. The CCDR helps to p= erform that correlation and to track the delegation, thanks to the actor_token and the act claim. Since= the CCDR establishes that the Delegate is authorized to act for the Initia= tor =E2=80=94 whose c= lient_id is the Deciding whether or not to issue the ID-JAG remains= the IdP's responsibility, through the security policies its administra= tor defines in the enterprise context. The MCP proxy is the only instance w= ith visibility over the upstream servers' scopes, so it is its responsi= bility to make the appropriate request to the IdP to obtain those scopes in= the ID-JAG token, which then allows it to request them from the Resource A= uthorization Server.

One of the motivations for this policy-based approv= al is to limit human interactions to approve actions that can be approved a= utomatically in an enterprise context, where the resources belong to the or= ganization and where an entitlement/permission system is already in place t= o control access based on the employee's identity.

Best regards,
Eric


Le=C2=A0mer. 29 juil. 2026 =C3=A0=C2=A015:31,= Karl McGuinness <me@karlmcguin= ness.com> a =C3=A9crit=C2=A0:

Barak,

Thanks for the framing. Answering the four points.

Who decides scope in the broker= ed shape.

= D-JAG's consent model isn't consumer OAuth's. ID-JAG moves the = consent decision to the admin/IdP layer by design. Users don't consent = to each cross-app grant. Enterprise admins configure which cross-app access= is permitted, and the IdP enforces at ID-JAG issuance time.

The brokered shape inherits this.= Gateway-decides-scope isn't a new consent question. It's the same = enterprise-managed model with one more admin-configured party (the broker) = in the chain: user consented to enterprise SSO, admin configured the CCDR b= etween agent and broker, IdP enforces both at Token Exchange time.

Bolting consumer-style per-= scope consent onto the brokered shape is a legitimate design point but it m= oves away from the enterprise-managed model ID-JAG was built for. Any I-D t= hat adds it is really adding a new consent layer on top of ID-JAG.

Access token vs. ID= Token as the inbound artifact.

You're picking up something real. Eric's orig= inal topology in=C2=A0#114=C2=A0carried the inbound autho= rization decision (this app may use this gateway) via an access token audie= nced to the gateway. The current=C2=A0sketches=C2=A0replace that = with the administered CCDR.

Both are admin/IdP-controlled but distribute the decision differen= tly: access-token-audienced-to-gateway is per-authorization (minted at auth= time), the administered CCDR is per-deployment (configured at the IdP).

The Enterprise Broker= deployment pattern brings per-invocation binding back in its=C2=A0Authenticated Handoff section, where the broker validate= s a Broker-audience access token accompanying the ID Token. That composes w= ith the CCDR rather than replacing it. The base Cross-Client Delegation pro= file doesn't require it. The deployment pattern strongly recommends it.= Worth being more explicit in the base profile about this being a deploymen= t-selectable enforcement point.

Cross-organizational gateway.

Deliberately out of scope for both= sketches. The current profile relies on the IdP administering both endpoin= ts of the CCDR, which works within an organization but not across.

Meiling Chen's use-case= s work (#17=C2=A0and=C2=A0#18) is tracking this.=C2=A0draft-reece-wimse-cross-org= -delegation=C2=A0is approaching the same problem fr= om the WIMSE side. My take is it needs its own mechanism (federation, attes= tation, or a Chain Authority) that composes with cross-client delegation bu= t doesn't fit inside it.

Explicitly stating the allocation.

Fully agree. The current sketc= hes assume gateway-decides-scope with administered trust as the consent bas= is (consistent with ID-JAG's enterprise-managed model). Consumer-style = user-consent-per-scope is an explicit non-goal. That belongs in the Applica= bility Statement of any I-D that comes out of this.

Thanks again for the framing.

-Karl


On Wed, Jul 29, 2026= at 5:55=E2=80=AFAM Barak Shelef <barak@oasis.security> wrote:
Hi al= l,

First time posting here, so please take this as a question rather= than a proposal. I have been
following this thread along with issues #1= 14 and #115, and there is one framing that helped me
understand the disa= greement. 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 thin= k that is the choice underneath the mechanism debate. Either the app
kee= ps deciding scope, in which case the gateway is not really the permission b= oundary that deploying a
gateway usually implies, or the gateway decides= scope and brokers across trust boundaries, in which
case we need anothe= r way to carry the user and app identity. Both look like valid architecture= s 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, sc= ope), and Jeff's point that only the gateway knows the backend
resou= rce expectations suggests the gateway is the one naming the scope. If so, t= he IdP is deciding on a
scope the app never requested, against consent t= he 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.<= br>
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
T= oken instead, which carries who the user is but not that grant. Is dropping= the inbound authorization
decision deliberate, or just not the part und= er 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, enterpris= e-controlled clients, and
Kieran noted the guarantees stop being free on= ce 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 inte= nded
answer is there, or whether that is deliberately out of scope for n= ow.

If the cross-client delegation work is becoming its own I-D, say= ing 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.

--<= br>Barak Shelef
Head of Technology, CTO Office
Oasis Security
On Tue, = Jul 28, 2026 at 9:10=E2=80=AFAM Lombardo, Jeff <jeffsec=3D40amazon.com@dmarc.ietf.= org> wrote:

The tw= o 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]=C2=A0and scopes acquisition through a new minted token before = aiming for the JAG based on backend resource expectations that only the Gat= eway can know.

Two side notes on this thread:

1. the IDP definitively need to keep track of all those exchanges and perfo= rm some decisioning on if a / the next minting needs to happen. One thing t= hat appeared clearly last week is that IDPs will need to be equipped with p= olicy 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 esp= ecially for long chain. I am not sure we finally solved this one.=

=C2=A0

Jeff

=C2=A0

From: Kieran Sweeney <kieran@kierans.net>
Sent: July 28, 2026 6:20 AM
To: Karl McGuinness <me@karlmcguinness.com>
Cc: morganLR <morganLR=3D40proton.me@dmarc.ietf.org>; oauth <oauth@ietf.org>; Eric= Leleu <eric.leleu=3D40graviteesource.com@dmarc.ietf.org>
Subject: [EXT] [OAUTH-WG] Re: Question on ID-JAG topology: Public Ag= ent + API Gateway / MCP Proxy scenario

=C2=A0

CAUTION: This email originated from outside of the organi= zation. Do not click links or open attachments unless you can confirm the sender and know the content is safe.<= /u>

=C2=A0

AVERTISSEMENT: Ce courrier =C3=A9lectronique provient d= =E2=80=99un exp=C3=A9diteur externe. Ne cliquez sur aucun lien et n=E2=80= =99ouvrez aucune pi=C3=A8ce jointe si vous ne pouvez pas confirmer l=E2=80=99identit= =C3=A9 de l=E2=80=99exp=C3=A9diteur et si vous n=E2=80=99=C3=AAtes pas cert= ain que le contenu ne pr=C3=A9sente aucun risque.

=C2=A0

Karl,

A few points on the ICA draft,= aimed at where it may need tightening. The direction is right; these are t= he parts I would want nailed down before it is implementable.=

  1. The per-boundary round trip i= s on the interactive path. The draft prices the chain in round trips but do= es not say the continuation resolution sits inside a user-visible agent tool call. That is where implementers wil= l cache the resolution to cut latency, and a cached resolution is where the= cross-audience linkability the design prevents comes back. The draft shoul= d state that continuation resolution is per-invocation and specify what an implementation may and may not cache= across audiences.
  2. Spe= cify the public-client entry point. The draft assumes mutually authenticate= d 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 i= s 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 reques= t path. The draft could say whether it is mandatory, and if it can be absent or unavailable, what the chain= 9;s guarantees degrade to without it. As written, the security properties a= re defined only for the full deployment, not the partial ones that will get= run.
  4. Lea= d with revocation; it is the load-bearing property. Resolving each continua= tion 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. Concretel= y, 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 (#11= 4) has been converging on the same chain semantics from the mint side, so t= he two are worth reconciling.

=C2=A0

Best,=C2=A0

Kieran

=C2=A0

On Sun, Jul 26, 2026 at 4:04=E2=80=AFPM Eric Leleu <eric.leleu=3D40gravite= esource.com@dmarc.ietf.org> wrote:

Hi Max, Morgan, and Karl,

Thank you all for the valuable feedback.

Following Morgan's suggestion, I=E2=80=99ve opened two issues regard= ing this use case:

  • On the oauth-identity-assertion-au= thz-grant GitHub repository [1]
  • As a pr= oposed use case in draft-chen-oauth-ag= ent-authz-use-cases [2]

Karl,=C2=A0I 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 unint= ended audience.

Max,=C2=A0Your proposal around the elicitation flow seems to solv= e the immediate issue of granting access to upstream servers. However, as M= organ pointed out, we lose visibility into the delegation chain, which isn&= #39;t ideal (even if it might be the best available workaround given the current state of the draft).<= /p>

Best regards,

[1] https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/114=

[2]=C2=A0https://github.com/M= aisy-ML/Agent-Authorization-Use-Cases/issues/16

=C2=A0

Le=C2=A0ven. 24 juil. 2026 =C3=A0=C2=A021:02, morgan= LR <morganLR=3D40proton.me@dmarc.ietf.org> a =C3=A9crit=C2=A0:=

Max,

=C2=A0

This is a useful decomposition, and I think your own parenthetica= l identifies the crux: the workaround makes the gateway the subject, and ev= erything upstream of it sees only the gateway. That is not an implementation wrinkle, it is the general beha= vior of re-subjecting intermediaries: each mediation hop that acquires auth= ority under its own identity collapses the chain behind it, and whatever th= e deployment needed the chain for (per-agent policy, audit attribution, differential revocation) has to be r= econstructed some other way.

=C2=A0

The actor_token idea does help, but it is worth being precise abo= ut 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 ordinar= y 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 extens= ion of the chain is a round-trip to it. That is a coherent architecture, and for the fullest articulation o= f it I would point at Karl's Identity Continuation Assertion note, whic= h works out the caller-pushed, control-plane-resident version of exactly th= is 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.

=C2=A0

One assumption in the scenario deserves flagging, because it is w= here 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 o= wn 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.=

=C2=A0

Which is my main suggestion: this thread has produced better depl= oyment 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 reposit= ory; the gateway-collapse observation and the one-orbit assumption both bel= ong 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

=C2=A0

Morgan

On Thursday, July 23rd, 2026 at 12:34 AM, Max Gerber= <mgerber=3D40twilio.com@dmarc.ietf.org> wrote:

Thinking out loud: One way to do this today is for t= he 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 t= he 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.

=C2=A0

When the Agent makes requests to the Gateway, the Ga= teway can use the ID Token to retrieve an ID-JAG for the upstream MCP AS. T= his ID-JAG will only identify the Gateway client, not the Agent itself. Thi= s 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.

=C2=A0

Would having the Gateway pass in the Agent's acc= ess 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.<= /u>

=C2=A0

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

Eric,

=C2=A0

Good question, it is my understanding that the two p= aths you named do different jobs, so I'd suggest both, in this order gi= ven the timing this week.

=C2=A0

1. GitHub issue against the ID-JAG repo, today if yo= u can. That's the right vehicle for the narrow question: does ID-JAG ad= dress this topology, or is it out of scope by design?

=C2=A0

2. The use-case record, for the broader point. The c= hairs have been clear that use cases and requirements come before mechanism= selection, and there is an active collection effort (draft-chen-oauth-agen= t-authz-use-cases is the current gathering point).

=C2=A0

3. If you want it durable under your own name, a sho= rt individual problem-statement I-D is always an option.

=C2=A0

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

=C2=A0

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 ou= t time to properly go through the references you both pointed to.

=C2=A0

Morgan, one practical question on process: you menti= oned this topology deserves to be in the record the working group is buildi= ng this week.

I'm not familiar with the actual procedure for t= hat. Should I open a GitHub issue against the ID-JAG repo, or write it up a= s a separate use-case/problem statement?

If the latter, where should that go? Happy to follow= whichever path is expected.

=C2=A0

Thanks again,

Eric

=C2=A0

Le mer. 22 juil. 2026 =C3=A0 18:44, Karl McGuinness = <me@karlmcgui= nness.com> a =C3=A9crit :

Extending ID-JAG to support public clients is an ope= n topic for discussion. I encourage you to read these issues and chime in w= ith additional use cases, concerns, or feedback

=C2=A0

https://github.com/oau= th-wg/oauth-identity-assertion-authz-grant/issues/85

https://github.com/oa= uth-wg/oauth-identity-assertion-authz-grant/issues/113

=C2=A0

The gateway scenario you outlined is similar to one = where folks need to make a second hop after exchanging the ID-JAG for an ac= cess 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, bu= t 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/draf= t-mcguinness-oauth-id-continuation-assertion.html and for this reason I haven't submitted it yet as an I-D because it st= ill 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 p= articular 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 profi= le.

=C2=A0

-Karl

=C2=A0

=C2=A0

=C2=A0

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 mechanism. It is wor= th naming why it arises structurally: an identity assertion is audience-loc= ked to the party it was issued to, and delegation through an intermediary r= equires 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 ac= tor_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 sepa= rately authorizing the actor as a registered intermediary for that audience= , resolves your topology without new machinery. The cost is that the IdP mu= st now hold policy about which intermediaries may act for which clients, and the exchange remains a per-upstream, per-ho= p round trip to the IdP: the gateway mints one ID-JAG per upstream AS, on t= he 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 propert= y class (attenuation verifiable from the artifact alone, no runtime callbac= k 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 topolog= ies 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 sta= tements before solutions, and agent-behind-gateway with a public-client age= nt is arguably the most common deployment shape MCP has produced. I would encourage writing it up exactly as you hav= e here.

Morgan

=C2=A0

On Wednesday, July 22nd, 2026 at 7:23 AM, Eric Leleu <eric.lel= eu=3D40graviteesource.com@dmarc.ietf.org> wrote:

Hi all,

I'd like to raise a topology question about the ID-JAG draft (draft-iet= f-oauth-identity-assertion-authz-grant) that I expect to come up often as a= gentic/MCP deployments grow, and I don't think the current text resolve= s it from my understanding.

Topology Description:
----------------------------

- An AI coding agent (e.g. Claude Code) acts as an MCP Client. It is regist= ered at the enterprise IdP as a *public* client (native/CLI app, PKCE, no c= lient 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/reso= urce is an MCP Gateway sitting in front of it.
- The MCP Gateway aggregates several upstream MCP servers. Each upstream se= rver is protected by its own Resource Authorization Server, and each of tho= se 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 redemption at that= AS.

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

Section 4.3.3 [1], "IdP Token Exchange Processing Rules", require= s that when the subject_token presented in the Token Exchange call is an id= entity 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_i= d of the client authentication of the request". In the Gateway topolog= y above, this rule creates a dilemma where neither party can execute the ex= change:


1. The agent is the audience of the ID Token, but the agent has no reason t= o call Token Exchange itself =E2=80=94 it doesn't know which upstream A= S/audience a given MCP tool call needs, and as a public client it's als= o 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 ta= rget 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, n= ot 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 architect= ure 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 th= e identity assertion's audience differs from the calling proxy's cl= ient_id?


Thanks,
Eric


[1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-a= uthz-grant#name-processing-rules

=C2=A0

--


=C2=A0

Eric LELEU

Staff Software Engineer

E eric.leleu@graviteesource.com

=C2=A0

Hold Nothing Back

<= u>

=C2=A0

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


=C2=A0

--


=C2=A0

Eric LELEU

Staff Software Engineer / AM Teach Lead<= u>

E eric.leleu@graviteesource.com

=C2=A0

Hold Nothing Back

=C2=A0

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

=C2=A0


=C2=A0

--


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /u>

=C2=A0

Eric LELEU=C2=A0

Staff Software Engineer / AM Tech Lead

E eric.leleu@graviteesource.com=C2=A0

=C2=A0

Hold Nothing Back

=C2=A0=C2=A0

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


=C2=A0

--

Kieran Sweeney
310 - 330 - 6458

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


--


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0


Eric LELEU=C2=A0

Staff Software E= ngineer / AM Tech Lead

E eric= .leleu@graviteesource.com=C2=A0


Hold Nothing Back

= =C2=A0=C2=A0=
--0000000000009d9e340657c3d0fa--