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 9024D123E3EE9 for ; Tue, 4 Aug 2026 22:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785908975; bh=Rd6fIjpnK7QYWGh83PNqLK7YfDbwSdArunLiuZPRzoo=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=I46tCSIzWGh8f9DogaUaqpBwbx5cSGjkGXe85nENYcExCO/zSUOzPhVj20Ej6xvlq B/t7ywRcnvEyTbOTbMYnE3dlLdWlnqnGJiKbkIjbBRQu1INLVRtZexruS1un3zEzxO ZyhLSspHCwa1RUybSOVx7cOJmA3J3nt80e1UsnYs= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.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, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=karlmcguinness.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 SoUU9Pkupt19 for ; Tue, 4 Aug 2026 22:49:33 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 9FCCA123E3EE1 for ; Tue, 4 Aug 2026 22:49:33 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4954a32cf1eso2414825e9.3 for ; Tue, 04 Aug 2026 22:49:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785908967; cv=none; d=google.com; s=arc-20260327; b=eEl7BJysAxnF8ipwNWE4pRpL9nRyqrIBdmuH2RjCMicRdY9JhcE0CImua5AsAaYjnj E3xLm1aGpUzCXw0gSX28hsm2OxkFtLB3zN4wxnymSOceWjgZjqLy67+vBW12/Jq5C7nU 5X09l3rgl/GhtNQKUWaPauFKtioHUNFCxGni/x7gSsoi7FvtjYSm2ntyhPsJt+ylhByY jPJchu/DHT2KPbTpcl3PfrQBzSBLZHOWTVrVpjr73OyzvbbcDHFDj3cuBLVBS+UQGsgH xRHd/n+PFEkWJImmJjRQoRZ2axg5Nkkq39mrq0bCHwO9Zu/gyxgmgvbkG0GdGesfbRol UxPw== 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=7t6ywy0p7uhmKAFfyVdaF3LvNpqaDza6QgpKXUmSOGs=; fh=vK6xGK2rzO9140KhimOPwRM8b9vu3BH+M01KfXO7FMM=; b=C8hYwa/TR6M8JbEklsqgCHqQnZV/vjQ9I6fy+Io2y/O8N5J8gFWe8ZSB0R0lufnfvS 0nqcdI+tLCwU3rty65xhawQJj7HPxShcCzTuiOQSmZTRMve2LeT1FoBRrjE0qEMqWp2H k+Slt4GqVMq0L8ZxWSkQYiJFrYEcj8+KuDfUV0pNsEFYeZcw1gGD65pYZt3zG+zw4DXF MiORLQpq5CvQMeFDYV/UNC9aqTK9zzTqkGoTT4r+lgALn+ig3AXx26BIogAsw3EbJBUJ jX46fMjgFb69x9AfsJfQNKzGKpFUpAbbl/qzI4wcn+YOYbXEmaqa4GB/ACQ4FOiZj9Kt S5pg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karlmcguinness.com; s=google; t=1785908967; x=1786513767; 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=7t6ywy0p7uhmKAFfyVdaF3LvNpqaDza6QgpKXUmSOGs=; b=WkdjvKQJ4LCNmCQlllWje++dFqnFAP8746rHZIMe7E0ZR61FHMftDgGy6b8VPYwNVT fU3rQPzVKfLO5k4ULX5Ui1o3wkiYBP65GSbx8RoGGd3T7WaYT6EejilH+Go0qcXajDo3 ki5+y9+S3Ht7Yctj1D3TnGf+I8tZJonU89K0nY0ytjCGwtZPjRurA03B10LzdoGh0w9K X6Frh02+Tmf7vnRbuMxVN0tbeMjXAyc0tznjbQq6Cc/Aj6t1ubUZvhA/uLL2zcPgC3sp pag5YldbfzxhU7V+TRYzW6w9xtiC7WcDijHJwGieUyGoOO84cBeayBgFjIXp1H+1FBTM DD2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785908967; x=1786513767; 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=7t6ywy0p7uhmKAFfyVdaF3LvNpqaDza6QgpKXUmSOGs=; b=Losvk+9xRDuApWb4966mZSjFw4tvRrGWO1gZJPfsmw671PtQ3O7++Du7yxvPCIEHYB ienWFIutLVon7QrIh4FjniS8u3q/Gv1T9jZd64d/HXNhs5CyqCtfKdWa92GNY6Nyv+3e f5OB3/yygMcL1H++EOaWbPGvMX/T4QaVRAnaiCRb9DF/rOYYSVSPPSs9auIoR5ncRjSK H2Ho+TUTPT43ddNQwYXTq1vDBcvVpC0aG6xuLuAD1b8Kz0Z9PnR1EsIPXxVOY4xhubIy 9pKFmB6fFLERgVWI+zd7M9z8rmkDFJ7jhPJ1jYQdcALtisMJvPyqa6uRfCr9CKEjlMU7 zw1g== X-Forwarded-Encrypted: i=1; AHgh+RrCYRNFJH8JlMqrNiOcFX0bsm5DjgcB24OztnOKGoTo2s+8SbUEZL9yRy2/C3eMcGCFGjjOyg==@ietf.org X-Gm-Message-State: AOJu0YzuDzHCysVPdTjOsNdF4CODnfmirZBJh+jiMIvczfn3R75j1wHw uSKRoDvH4vbolGWG1OSWsu7GMAgbA2R3NFrkyPmj9UA8zJbZk8JON8RnQ+QLlTp7Ka6UKtMSjTm y/EBDesJbP6kW8rlAPv5/i2MzxqpwCdIpGl2lixnYkw== X-Gm-Gg: AR+sD105uyMuuaq4pdndGUCARA4N6lx/EgztK1QleKSLfFTrvcf1RCNcSFngpmDnZj9 99Rq4khLXXkhQvS/LsqaDD9hR6H2rXWrP5YvFk989jDZOzJsafExbKQXPAwhKRYFzJFK3w9ULwT eT+dzGlUHf06aCEil1lSGBc5j5lQDELW4NiBRZOmfKB8ZWikufFHt0avXia3JGq5gMOHXhQkIPU hNvFNc7Knj0UzQfrQpq5D5Vq9ro9wkuK1FeLMD92Ql4oYxxfVAHz5p8D+JmZPaGK7gB/FXiH7M2 EusU7byRX1GkNYjE9lYCQMc3kBUgF012r3Lj5xkrzkQn51IavDpSneQSMGUI+/t5lWlUqDCdalr cxoXVhqTgBhUIqArSvILQkiIoYF5gYwJnpLDBymqVT+TkaY29Kzdl0kM8ScTqwmTY5K3qozk/Xb VsQgMreWHi5A== X-Received: by 2002:a05:600c:28c:b0:499:4ada:981d with SMTP id 5b1f17b1804b1-4994e73240amr30135655e9.7.1785908966352; Tue, 04 Aug 2026 22:49:26 -0700 (PDT) MIME-Version: 1.0 References: <9Cyua32o8mx61peJVon_YMol2bzYN8b8taCAvTlMmqGNrw2KsNdcVjjxcbDaXW1_JXmBVNbAUyD1SI8QLjRxlY7WYtQ3oGtpDRlfLoaA6cw=@proton.me> In-Reply-To: <9Cyua32o8mx61peJVon_YMol2bzYN8b8taCAvTlMmqGNrw2KsNdcVjjxcbDaXW1_JXmBVNbAUyD1SI8QLjRxlY7WYtQ3oGtpDRlfLoaA6cw=@proton.me> From: Karl McGuinness Date: Tue, 4 Aug 2026 22:49:13 -0700 X-Gm-Features: AUfX_mzbI0c-AmpZ7fuRgBHcReeGdv2nVEBc2ozxOAWwaksqKMko4VMlhJxb4eg Message-ID: To: morganLR Content-Type: multipart/alternative; boundary="0000000000008a78750658465585" Message-ID-Hash: WU425C4OANGC3CSBX4DENA7CQHSWQWUV X-Message-ID-Hash: WU425C4OANGC3CSBX4DENA7CQHSWQWUV X-MailFrom: me@karlmcguinness.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: Paul Carleton , Yaron ZEHAVI , "oauth@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_New_I-D=3A_draft-carleton-workload-authz-gran?= =?utf-8?q?t_=28Workload_Authorization_Grant=29?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000008a78750658465585 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Morgan, *two topologies* Aligned with the acquisition/binding framing (thanks, that was a useful sharpening). One clarification on the concentration critique though: "...issuer of record for identities it did not mint" applies to a different deployment than the topology ID-JAG assumes. In that deployment, the IdP issuing the ID-JAG mints the identity the RAS consumes, regardless of upstream credential or assertion. This holds for both patterns visible today in the user / on-behalf-of case, and extends to workload/agent Principals via work in flight: - *IdP Owned Principal.* The IdP authenticates the Principal directly and owns the identity end-to-end. - *IdP Brokered Principal.* The IdP delegates authentication upstream (SAML/OIDC federation for users, platform-issued credentials like Kubernetes ServiceAccounts / SPIFFE SVIDs for workloads/agents) but stil= l establishes the downstream identity. The IdP propagates lifecycle change= s to the RAS via SCIM (users today, agents via draft-wzdk-scim-agent-resource ) or JIT at first presentation. Both patterns apply to enterprise and platform IdPs. A platform IdP MAY delegate authentication upstream while remaining authoritative for the downstream identity, provided it owns that identity's lifecycle (provisioning, revocation, JIT) rather than acting as a pure passthrough. The "identities it did not mint" concern applies to the passthrough deployment, which I feel isn't a good fit for ID-JAG. RAS trust in the IdP largely rests on the IdP being the identity issuer of record downstream, not just a signing intermediary. *claims vocabulary boundary* Issue #73 as originally proposed spans both cases: an own-behalf mode (sub = is a workload/agent identifier typed via sub_profile, no user in the token) and an explicit-delegation mode (sub =3D user, act =3D client/workload). Yo= ur concern about the two vocabularies quietly merging applies to the union, and the same disambiguation problem doesn't stop at the ID-JAG assertion grant. Once the ID-JAG is exchanged at the Resource Authorization Server, the resulting access token also *needs to distinguish own-behalf from with-principal, or every Resource Server ends up re-deriving it from context*. This is what "distinguishable by construction" was meant to avoid= . Explicit vocabulary for these distinctions (Actor Profile fo= r delegation, Entity Profiles ' sub_profile / client_profile for Principal type) is designed to carry across both assertion grants and access tokens, keeping the distinction visible end-to-end if the RS profiles it in its issued tokens. Since a Resource Server sees a mix of own-behalf and with-principal tokens over time, the vocabulary is worth carrying at that layer regardless of grant. *working position* My working position on #73: the explicit-delegation piece was already moved to the Actor Profile fa= mily with its own claim vocabulary and processing rules, designed to compose with ID-JAG rather than replace it. Happy to align Actor Profile's evidence vocabulary with the separate with-principal work you have in flight. The point of separating Actor Profile from ID-JAG was to keep this vocabulary evolvable, with Actor Receipts and Actor Proofs add= ed as companion drafts. What still seems to be valid for ID-JAG under #73 is the own-behalf extension: allowing subject_token to carry a client acting as itself, so a workload/agent Principal appears directly as sub. This is where ID-JAG's coverage overlaps with WAG's scope, and where your "distinguishable by construction" concern applies most directly. Whether that lands as one draft or two aligned drafts is worth working through with the WG. Under #73, sub_profile (and client_profile) are proposed for exactly this purpose: values like user, service, ai_agent, combined with the presence or absence of act, give a construction-level distinction between own-behalf and with-principal at the grant layer, and at the access-token layer when the RS adopts the same vocabulary. This reduces the need for a RAS or Resource Server to infer from context. If there's WG interest, one direction would be a shared "deployment mode" framing across the two drafts, with WAG carrying the direct platform=E2=86= =94RAS mode and ID-JAG carrying the IdP-integrated mode, cross-referenced from each side. Aligning on a shared subject_token JWT shape and sub_profile vocabulary would let a RAS accepting either path apply the same processing rules. Is sub_profile (typed Principal in the token) enough of a construction-level distinction on the own-behalf side, with Actor Profile or a related delegation-evidence profile carrying the with-principal side? -Karl On Tue, Aug 4, 2026 at 7:42=E2=80=AFPM morganLR wrote: > Paul, Karl, Aaron, Yaron, > > A few observations from the requirements side, since the draft was kind > enough to position against it. > > On the deployment-shape discussion: it may help to name what the two > shapes are actually deciding. In the vocabulary the requirements draft's > -02 revision adopts, every cross-boundary trust story has an acquisition > step (how the relying side obtains trust material for an issuer at all) a= nd > a binding step (whether that material represents the party it claims). > WAG's admin-level entry per tenancy performs both in one administrative > act, directly between platform and resource AS, and amortizes it across > unbounded ephemeral instances via just-in-time acceptance; the > IdP-integrated shape in issue #73 performs the same two steps once, betwe= en > IdP and resource AS, and then amortizes across platforms as well as > instances. Both are prior-arrangement models with different concentration > trade-offs: the direct shape keeps the trust decision with the party > consuming it at the cost of one entry per tenancy; the brokered shape > collapses entries at the cost of making the IdP the issuer of record for > identities it did not mint and a runtime dependency for every platform > behind it. Which trade a deployment wants seems genuinely situational, > which argues for Paul's separate-draft instinct with aligned token shape, > rather than one model absorbing the other. And for completeness: the case > where no prior arrangement can exist at all, first contact between > organizations with no admin on either side to perform the entry, is the > lane the requirements draft exists for, and neither shape here claims it. > > On claims vocabulary, one boundary drawn now will save this thread's > successors a painful divorce: WAG's scope is the agent acting as itself, = no > human principal in the token, and the claims that case needs (instance > identity, tenancy, attestation context, the RFC 9068 authorization > attributes) are structurally different from the with-principal case, wher= e > delegation and authorization evidence must be conveyed and where the > requirements impose invariants (principal binding and non-alterability > along the chain, dual-axis authorization, execution-time > human-authorization evidence) that own-behalf tokens never carry. Issue > #73's relaxation of subject_token toward client assertions and attestatio= ns > is exactly where these two vocabularies could quietly merge, and they > should not: whatever registry these claims land in, I would ask that > own-behalf attributes and with-principal delegation evidence be > distinguishable by construction, not by convention. The with-principal > evidence vocabulary is adjacent work I intend to bring forward separately= , > and I will keep it aligned with whatever this thread settles for the > own-behalf case. > > On Paul's question 3, briefly, because the working group just paid for > this lesson: audience handling should inherit rfc7523bis's sole-audience > discipline exactly, one audience, the token endpoint's issuer identifier, > no relaxation toward relationship-inferred audiences. The > audience-injection findings were about assertions consumable by parties > other than the one named, and a grant format born after the remedy should > be strict from birth. > > And Yaron, thank you for the production datapoint; PoP-constrained grants > running at bank grade is evidence the whole space should be citing, and > cnf-in-the-grant seems clearly right for WAG as well. > > Morgan > On Tuesday, August 4th, 2026 at 8:18 PM, Karl McGuinness < > me@karlmcguinness.com> wrote: > > +1 > > The changes we made to relax the definition of ID-JAG IdP from Enterprise > IdP to as Aaron indicated, the role of identity issuer for the RAS, was t= o > enable a "Kubernetes"-like deployment model with a Platform IdP. We also > relaxed actor_token constraints to enable profiling ontop for instances. > > Issue #73 is just proposing to do the same for Principal and relaxing it > to allow Client Assertion/Attesation/Client Instance Assertion as a > subject_token instead of an id_token with the IdP brokering subject, > claims, scopes. resource to the downstream RAS for client as subject. > > -Karl > > On Tue, Aug 4, 2026 at 6:06=E2=80=AFPM Aaron Parecki = wrote: > >> fwiw a deployment option for ID-JAG could be a consumer platform issuing >> ID-JAGs itself. This is outlined in appendix A.2 >> https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-auth= z-grant-04.html#appendix-A.2 >> but imagine the case where the "CIAM Platform" in that example is actual= ly >> the same platform as where the client is running. The key thing is the >> relationship between the Resource AS and the ID-JAG issuer. The "IdP" ro= le >> in ID-JAG is not limited to being what you typically think of as an >> enterprise IdP. >> >> >> On Tue, Aug 4, 2026 at 5:57=E2=80=AFPM Paul Carleton wrote: >> >>> >>> Karl, I agree that shape sounds a lot like the "BYO-IdP" model listed i= n >>> the open issue. A few things I want to be true: >>> >>> - An RS adopting ID-JAG has an easy time adapting to accept WAG >>> (i.e. same / similar token shape + similar JIT semantics) >>> - An RS adopting WAG has an easy time adapting to accept ID-JAG >>> - An RS adopting WAG does not necessarily need to integrate with an >>> IdP >>> >>> This last bullet point pushes me toward making this a separate draft. >>> The initial and simplest deployment shape I am thinking of is similar t= o a >>> kubernetes cluster's OIDC provider being used in a workload identity >>> federation flow. In that deployment, the kubernetes cluster is not a >>> full-blown IdP, it is just trusted to issue identities to its pods. The= re >>> is no expectation that Kubernetes clusters register their pod identitie= s >>> with an IdP. >>> >>> Similarly the agent platform is not a full IdP, it is just responsible >>> for giving identities to the agents in its domain. I agree that there a= re >>> benefits to the IdP-integrated deployment model, but I want to allow fo= r >>> the simpler model initially. >>> >>> ID-JAG could also allow for platform's issuing their own non-IdP tokens= , >>> but that feels like bypassing the IdP when it is human-based access. Wi= th >>> workloads, it feels more natural to have a deployment model with the >>> platform being directly responsible for issuing tokens (similar to k8s = oidc >>> providers). >>> >>> That being said, the token shape, etc., should be similar regardless of >>> which draft its specified in, so it seems worth aligning regardless of >>> where it ends up. The claims I want to align on here would also be rele= vant >>> to ID-JAG JIT provisioning. >>> >>> Yaron -- thanks for this. I agree we want PoP constraining. Re: OAuth >>> SPIFFE Client Authentication >>> , >>> I have sketched out the shapes here >>> . >>> I think it solves a slightly different problem in that it relies on the= RS >>> understanding the SPIFFE credential, where in this case I want the WAG = to >>> be compatible with SPIFFE but not require SPIFFE. I would lean more tow= ards >>> CIMD + private_key_jwt for this particular pattern. >>> >>> On Mon, Aug 3, 2026 at 5:20=E2=80=AFPM Yaron ZEHAVI >> 40rbinternational.com@dmarc.ietf.org> wrote: >>> >>>> Hello everyone, >>>> >>>> This looks like a useful addition to OAuth SPIFFE Client Authenticatio= n >>>> , >>>> which also uses workload identity as RFC7521/3 assertion JWTs, but sto= ps >>>> short of using them as JAGs, rather focuses on client authentication f= or >>>> other grants. >>>> >>>> A couple remarks: >>>> >>>> - This draft feels more naturally positioned as another profile of = identity >>>> chaining >>>> , >>>> alongside ID JAG >>>> . >>>> The latter originates from challenges of streamlining cross-domain = SSO for >>>> humans by removing friction, and now tackles further aspects in thi= s space >>>> such as required claims for JIT user provisioning, deferred respons= es etc. >>>> - The JAG should be PoP constrained, which is easily achievable by >>>> including the agent=E2=80=99s cnf claim in it. This mechanism is pr= oposed by OAuth >>>> 2.0 JWT Authorization Grant with DPoP Binding >>>> >>>> and we use it with good results in applicable JAG flows in our comp= any. >>>> >>>> Yaron >>>> >>>> >>>> Classification: GENERAL >>>> >>>> *From:* Karl McGuinness >>>> *Sent:* Monday, August 3, 2026 9:47 PM >>>> *To:* Aaron Parecki >>>> *Cc:* Paul Carleton ; >>>> oauth@ietf.org >>>> *Subject:* [OAUTH-WG] Re: New I-D: draft-carleton-workload-authz-grant >>>> (Workload Authorization Grant) >>>> >>>> This message is from an external sender - be cautious, particularly >>>> with links and attachments. >>>> >>>> I didn't see it as out of scope for ID-JAG because it's still acting a= s >>>> a principal managed by the IdP across domains which could have RAS spe= cific >>>> subject identifiers and authorization claims. IdPs already need to sol= ve >>>> the challenge of managing different principal types, lifecycle, >>>> entitlements, provisioning, etc. Its reduces a lot of cognitive overhe= ad >>>> for the developer to just think of ID-JAG as SSO where the upstream Id= P >>>> manages all the identity complexity as I just need issuer scoped `sub`= I >>>> can use for subject resolution. I acknowledge that my take my not be s= hared >>>> which is why I was hoping to get more attention on the issue. >>>> >>>> On Mon, Aug 3, 2026 at 12:36=E2=80=AFPM Aaron Parecki >>>> wrote: >>>> >>>> That's basically how we were thinking of it. I just felt like it was >>>> something a bit out of scope of the ID-JAG spec. But the idea is very = much >>>> to reuse the existing relationship established between the Resource AS= and >>>> IdP for ID-JAGs, and reuse it for workloads as well. >>>> >>>> On Mon, Aug 3, 2026 at 12:33=E2=80=AFPM Karl McGuinness >>>> wrote: >>>> >>>> Paul, >>>> >>>> Interesting draft. I'll have to dive in deeper. My initial reaction is >>>> that this draft lines up with something I raised in ID-JAG issue #73 ( >>>> https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issue= s/73): >>>> whether ID-JAG should also cover workloads acting as themselves. The i= ssue >>>> sketches Workload and Agent Identity SSO modes where the assertion's s= ub is >>>> the workload or agent itself rather than a chained user identity, whic= h is >>>> the same shape as your grant. The appeal of reusing ID-JAG was one sim= ple >>>> SSO model for agents, workloads, and clients, whether acting on behalf= of a >>>> user or as themselves, and it stays aligned with the standard identity= and >>>> authorization claims (which also bears on your question 2). >>>> >>>> The deployment I was picturing looks a lot like the Enterprise IdP >>>> variant in your issuer-placement open issue: the workload brings its >>>> credential to the IdP (a WIMSE WIT, say), the IdP issues the grant, an= d the >>>> platform picks it up by token exchange. If the resource AS is already >>>> integrated with the IdP, things get simpler, since the IdP is already >>>> handling agent lifecycle, entitlements, and governance through SCIM or= JIT. >>>> The resource AS ends up with one federation relationship instead of an >>>> allowlist entry per platform. >>>> >>>> Would love to hear your thoughts, as there was some initial positive >>>> signal on #73 but I was hoping for a larger discussion on the topic. >>>> >>>> Karl >>>> >>>> On Mon, Aug 3, 2026 at 11:06=E2=80=AFAM Paul Carleton >>> 40anthropic.com@dmarc.ietf.org> wrote: >>>> >>>> Hi all, >>>> >>>> Good to meet many of you in Vienna! >>>> >>>> I've posted an early individual draft based on some discussions had >>>> over that week. The draft profiles RFC 7523 for agent platforms: an ag= ent >>>> obtains access tokens by presenting a platform-signed JWT authorizatio= n >>>> grant at the resource's authorization server. I've also posted this to >>>> wimse@, since the identity in the grant is a WIMSE workload identity >>>> produced by ordinary WIMSE issuance and cross-domain federation; this = draft >>>> covers the OAuth-facing hop where an existing AS consumes it. >>>> >>>> This defines no new grant type, no new token format, and no change to >>>> RS-to-AS trust. A service with an existing OAuth deployment changes on= ly >>>> its token endpoint. Trust is one admin-level entry per customer tenanc= y >>>> with keys resolved by reference, and the AS accepts previously-unseen >>>> subjects under a trusted issuer just in time; there is no client >>>> registration step. >>>> >>>> Relative to adjacent work: same JWT-authorization-grant shape as ID-JA= G >>>> and draft-ietf-oauth-identity-chaining, but the subject is the agent >>>> workload itself rather than a chained user identity. The agent-as-clie= nt >>>> alternative (spiffe-client-auth, attestation-based-client-auth, CIMD) = is >>>> addressed in question 1 below. >>>> >>>> Datatracker: >>>> https://datatracker.ietf.org/doc/draft-carleton-workload-authz-grant/ >>>> Editor's copy: >>>> https://pcarleton.github.io/draft-carleton-workload-authz-grant/draft-= carleton-workload-authz-grant.html >>>> Repo: https://github.com/pcarleton/draft-carleton-workload-authz-grant >>>> >>>> Feedback I'm most looking for: >>>> >>>> 1. The draft treats the agent as the grant subject, not a new client I= D >>>> per-instance, and I think that's the right shape; thank you Brian Camp= bell >>>> for nudging me in that direction. It's one concrete stance in the ongo= ing >>>> client-instance discussion: consistent with the adopted stack (ATTEST, >>>> spiffe-client-auth, and the McGuinness drafts all keep one logical >>>> client_id and surface the instance elsewhere), and it keeps the adopti= on >>>> floor at "jwt-bearer, which already ships everywhere." Additional supp= ort >>>> for that framing would be helpful, or for concrete scenarios where >>>> subject-not-client breaks down. >>>> >>>> 2. Claim naming for platform-asserted attributes: reuse the RFC 9068 >>>> roles/groups/entitlements registrations, or register new names? (Relat= ed >>>> question posed to wimse@ about whether the AIMS work wants to own this >>>> vocabulary.) >>>> >>>> 3. Input on Audience handling relative to rfc7523bis. >>>> >>>> Requested cluster: Cross-Domain Chaining. Related: Client >>>> Authentication. >>>> >>>> Most sections are deliberately TODO. Feedback here or on the repo is >>>> welcome. >>>> >>>> Paul >>>> >>>> _______________________________________________ >>>> OAuth mailing list -- oauth@ietf.org >>>> To unsubscribe send an email to oauth-leave@ietf.org >>>> >>>> _______________________________________________ >>>> OAuth mailing list -- oauth@ietf.org >>>> To unsubscribe send an email to oauth-leave@ietf.org >>>> >>>> This message and any attachment ("the Message") are confidential. If >>>> you have received the Message in error, please notify the sender >>>> immediately and delete the Message from your system, any use of the Me= ssage >>>> is forbidden. Correspondence via e-mail is primarily for information >>>> purposes. RBI neither makes nor accepts legally binding statements via >>>> e-mail unless explicitly agreed otherwise. Information pursuant to =C2= =A7 14 >>>> Austrian Companies Code: Raiffeisen Bank International AG; Registered >>>> Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number:= FN >>>> 122119m at the Commercial Court of Vienna (Handelsgericht Wien). >>>> >>> > --0000000000008a78750658465585 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

M= organ,

two topologies

Aligned with the acquisition/binding = framing (thanks, that was a useful sharpening). One clarification on the co= ncentration critique though: "...issuer of record for identities it di= d not mint" applies to a different deployment than the topology ID-JAG= assumes. In that deployment, the IdP issuing the ID-JAG mints the identity= the RAS consumes, regardless of upstream credential or assertion. This hol= ds for both patterns visible today in the user / on-behalf-of case, and ext= ends to workload/agent Principals via work in flight:

  • IdP Owned Principal.=C2=A0The IdP authenticates the P= rincipal directly and owns the identity end-to-end.
  • IdP Brokered Principal.=C2=A0The IdP delegates auth= entication upstream (SAML/OIDC federation for users, platform-issued creden= tials like Kubernetes ServiceAccounts / SPIFFE SVIDs for workloads/agents) = but still establishes the downstream identity. The IdP propagates lifecycle= changes to the RAS via SCIM (users today, agents via=C2=A0draf= t-wzdk-scim-agent-resource) or JIT at first presentation.

    • Both patterns apply= to enterprise and platform IdPs. A platform IdP MAY delegate authenticatio= n upstream while remaining authoritative for the downstream identity, provi= ded it owns that identity's lifecycle (provisioning, revocation, JIT) r= ather than acting as a pure passthrough. The "identities it did not mi= nt" concern applies to the passthrough deployment, which I feel isn= 9;t a good fit for ID-JAG. RAS trust in the IdP largely rests on the IdP be= ing the identity issuer of record downstream, not just a signing intermedia= ry.

    claims vocabulary boundary

    Issue #73 as originally pr= oposed spans both cases: an own-behalf mode (sub=C2=A0is a workload/agent identifier typed= via=C2=A0sub_profile<= /code>, no user in the token) and an explicit-delegation mode (sub =3D u= ser,=C2=A0act = =3D client/workload). Your concern about the two vocabularies quietl= y merging applies to the union, and the same disambiguation problem doesn&#= 39;t stop at the ID-JAG assertion grant. Once the ID-JAG is exchanged at th= e Resource Authorization Server, the resulting access token also needs t= o distinguish own-behalf from with-principal, or every Resource Server ends= up re-deriving it from context. This is what "distinguishable by = construction" was meant to avoid.

    Explicit vocabulary for these distinctions (Actor Profile=C2=A0for delegation,=C2=A0Entity Profile= s'=C2=A0sub_pr= ofile=C2=A0/=C2=A0client_profile= =C2=A0for Principal type= ) is designed to carry across both assertion grants and access tokens, keep= ing the distinction visible end-to-end if the RS profiles it in its issued = tokens. Since a Resource Server sees a mix of own-behalf and with-principal= tokens over time, the vocabulary is worth carrying at that layer regardles= s of grant.

    working position

    My working position on #73: th= e explicit-delegation piece was already moved to the=C2=A0A= ctor Profile=C2=A0fa= mily with its own claim vocabulary and processing rules, designed to compos= e with ID-JAG rather than replace it. Happy to align Actor Profile's ev= idence vocabulary with the separate with-principal work you have in flight.= The point of separating Actor Profile from ID-JAG was to keep this vocabul= ary evolvable, with=C2=A0Actor Receipts=C2=A0and=C2=A0Actor Pro= ofs=C2=A0added as co= mpanion drafts.

    Wha= t still seems to be valid for ID-JAG under #73 is the own-behalf extension:= allowing=C2=A0subject= _token=C2=A0to ca= rry a client acting as itself, so a workload/agent Principal appears direct= ly as=C2=A0sub. This is where ID-JAG's coverage overlaps with WAG's scope, and w= here your "distinguishable by construction" concern applies most = directly. Whether that lands as one draft or two aligned drafts is worth wo= rking through with the WG.

    Under #73,=C2=A0= =C2=A0(and=C2=A0client_pr= ofile) are proposed for exactly this purpose: values like=C2=A0user,=C2=A0service,=C2=A0ai_agent, combined with t= he presence or absence of=C2=A0= act, give a construction-level distinction between own-beha= lf and with-principal at the grant layer, and at the access-token layer whe= n the RS adopts the same vocabulary. This reduces the need for a RAS or Res= ource Server to infer from context.

    If there's WG interest, one direction would be a share= d "deployment mode" framing across the two drafts, with WAG carry= ing the direct platform=E2=86=94RAS mode and ID-JAG carrying the IdP-integr= ated mode, cross-referenced from each side. Aligning on a shared=C2=A0subject_token=C2=A0JWT shape and=C2=A0sub_profile=C2=A0vocabulary would let a RAS = accepting either path apply the same processing rules.

    Is=C2=A0sub_profile=C2=A0(typed Principal in the token) enough of a constructi= on-level distinction on the own-behalf side, with Actor Profile or a relate= d delegation-evidence profile carrying the with-principal side?

    -Karl


On Tue, Aug 4, 2026 at 7:42=E2=80=AFPM morganLR <morganLR@proton.me> wrote:
Paul, Karl, Aaron, Yaron,

A few observations from the requirements side, since = the draft was kind enough to position against it.

On the deployment-shape discussion: it may help to name what t= he two shapes are actually deciding. In the vocabulary the requirements dra= ft's -02 revision adopts, every cross-boundary trust story has an acqui= sition step (how the relying side obtains trust material for an issuer at a= ll) and a binding step (whether that material represents the party it claim= s). WAG's admin-level entry per tenancy performs both in one administra= tive act, directly between platform and resource AS, and amortizes it acros= s unbounded ephemeral instances via just-in-time acceptance; the IdP-integr= ated shape in issue #73 performs the same two steps once, between IdP and r= esource AS, and then amortizes across platforms as well as instances. Both = are prior-arrangement models with different concentration trade-offs: the d= irect shape keeps the trust decision with the party consuming it at the cos= t of one entry per tenancy; the brokered shape collapses entries at the cos= t of making the IdP the issuer of record for identities it did not mint and= a runtime dependency for every platform behind it. Which trade a deploymen= t wants seems genuinely situational, which argues for Paul's separate-d= raft instinct with aligned token shape, rather than one model absorbing the= other. And for completeness: the case where no prior arrangement can exist= at all, first contact between organizations with no admin on either side t= o perform the entry, is the lane the requirements draft exists for, and nei= ther shape here claims it.

On claims = vocabulary, one boundary drawn now will save this thread's successors a= painful divorce: WAG's scope is the agent acting as itself, no human p= rincipal in the token, and the claims that case needs (instance identity, t= enancy, attestation context, the RFC 9068 authorization attributes) are str= ucturally different from the with-principal case, where delegation and auth= orization evidence must be conveyed and where the requirements impose invar= iants (principal binding and non-alterability along the chain, dual-axis au= thorization, execution-time human-authorization evidence) that own-behalf t= okens never carry. Issue #73's relaxation of subject_token toward clien= t assertions and attestations is exactly where these two vocabularies could= quietly merge, and they should not: whatever registry these claims land in= , I would ask that own-behalf attributes and with-principal delegation evid= ence be distinguishable by construction, not by convention. The with-princi= pal evidence vocabulary is adjacent work I intend to bring forward separate= ly, and I will keep it aligned with whatever this thread settles for the ow= n-behalf case.

On Paul's question= 3, briefly, because the working group just paid for this lesson: audience = handling should inherit rfc7523bis's sole-audience discipline exactly, = one audience, the token endpoint's issuer identifier, no relaxation tow= ard relationship-inferred audiences. The audience-injection findings were a= bout assertions consumable by parties other than the one named, and a grant= format born after the remedy should be strict from birth.

And Yaron, thank you for the production datapoint; Po= P-constrained grants running at bank grade is evidence the whole space shou= ld be citing, and cnf-in-the-grant seems clearly right for WAG as well.

Morgan
On Tuesday, August 4th, 2026 at 8:18 PM, Karl McGuinness <me@karlmcguinness.com<= /a>> wrote:
+1

The changes we made= to relax the definition of ID-JAG IdP from Enterprise IdP to as Aaron indi= cated, the role of identity issuer for the RAS, was to enable a "Kuber= netes"-like deployment model with a Platform IdP. We also relaxed act= or_token constraints to enable profiling ontop for instances.

Issu= e #73 is just proposing to do the same for Principal and relaxing it to all= ow Client Assertion/Attesation/Client Instance Assertion as a subject_token= instead of an id_token with the IdP brokering subject, claims, scopes. res= ource to the downstream RAS for client as subject.
<= br>
-Karl

fwiw a deployment optio= n for ID-JAG could be a consumer platform issuing ID-JAGs itself. This is o= utlined in appendix A.2 h= ttps://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-gr= ant-04.html#appendix-A.2 but imagine the case where the "CIAM Plat= form" in that example is actually the same platform as where the clien= t is running. The key thing is the relationship between the Resource AS and= the ID-JAG issuer. The "IdP" role in ID-JAG is not limited to be= ing what you typically think of as an enterprise IdP.

<= br>
On Tue,= Aug 4, 2026 at 5:57=E2=80=AFPM Paul Carleton <paulc@= anthropic.com> wrote:

Karl, I agree that shape sounds a lo= t like the "BYO-IdP" model listed in the open issue. A few things= I want to be true:
  • An RS adopting ID-JAG has an easy tim= e adapting to accept WAG (i.e. same / similar token shape + similar JIT sem= antics)
  • An RS adopting WAG has an easy time adapting to accept ID-J= AG
  • An RS adopting WAG does not necessarily need to integrate with a= n IdP
This last bullet point pushes me toward making this a s= eparate draft. The initial and simplest deployment shape I am thinking of i= s similar to a kubernetes cluster's OIDC provider being used in a workl= oad identity federation flow. In that deployment, the kubernetes cluster i= s not a full-blown IdP, it is just trusted to issue identities to its pods.= There is no expectation that Kubernetes clusters register their pod identi= ties with an IdP.

Similarly the agent platform is = not a full IdP, it is just responsible for giving identities to the agents = in its domain. I agree that there are benefits to the IdP-integrated deplo= yment model, but I want to allow for the simpler model initially.

ID-JAG could also allow for platform's issuing th= eir own non-IdP tokens, but that feels like bypassing the IdP when it is hu= man-based access. With workloads, it feels more natural to have a deployme= nt model with the platform being directly responsible for issuing tokens (s= imilar to k8s oidc providers).

That being said, th= e token shape, etc., should be similar regardless of which draft its specif= ied in, so it seems worth aligning regardless of where it ends up. The clai= ms I want to align on here would also be relevant to ID-JAG JIT provisionin= g.

Yaron -- thanks for this. I agree we want PoP constraining. Re: <= a href=3D"https://www.ietf.org/archive/id/draft-ietf-oauth-spiffe-client-au= th-02.html" style=3D"background-color:transparent;font-family:Arial,sans-se= rif;font-size:13.3333px" rel=3D"noreferrer nofollow noopener" target=3D"_bl= ank">OAuth SPIFFE Client Authentication, I have sketched out the shapes here= . I think it solves a slightly different problem in that it relies on t= he RS understanding the SPIFFE credential, where in this case I want the WA= G to be compatible with SPIFFE but not require SPIFFE. I would lean more to= wards CIMD + private_key_jwt for this particular pattern.

On Mon, Aug 3, 2026 at 5:20=E2=80=AFPM Yaron ZEHAVI <yaron.zehavi=3D40rbinter= national.com@dmarc.ietf.org> wrote:

Hello everyone,

This looks like a useful addition to OAuth SPIFFE Client Authentication, which also uses workload identity a= s RFC7521/3 assertion JWTs, but stops short of using them as JAGs, rather f= ocuses on client authentication for other grants.

A couple remarks:

  • This draft feels more naturally positioned as another profil= e of identity chaining, alongside ID JAG. The latter originates from challenges of streamlining cross-dom= ain SSO for humans by removing friction, and now tackles further aspects in= this space such as required claims for JIT user provisioning, deferred res= ponses etc.
  • The JAG should be PoP c= onstrained, which is easily achievable by including the agent=E2=80=99s cnf= claim in it. This mechanism is proposed by OAuth 2.0 JWT Authorization Grant with DPoP Binding and we use it with = good results in applicable JAG flows in our company.

Yaron


Classification: GENERAL

From: Karl McGuinness <me@karlmcguinness= .com>
Sent: Monday, August 3, 2026 9:47 PM
To: Aaron Parecki <aaron@parecki.com>
Cc: Paul Carleton <paulc=3D40anthro= pic.com@dmarc.ietf.org>; oauth@ietf.org
Subject: [OAUTH-WG] Re: New I-D: draft-carleton-workload-authz-grant= (Workload Authorization Grant)

This messa= ge is from an external sender - be cautious, particularly with links and at= tachments.

I didn't see it as out of scope for ID-JAG becau= se it's still acting as a principal managed by the IdP across domains w= hich could have RAS specific subject identifiers and authorization claims. = IdPs already need to solve the challenge of managing different principal types, lifecycle, entitlements, provisioning,= etc. Its reduces a lot of cognitive overhead for the developer to just th= ink of ID-JAG as SSO where the upstream IdP manages all the identity comple= xity as I just need issuer scoped `sub` I can use for subject resolution. I acknowledge that my take my not= be shared which is why I was hoping to get more attention on the issue. <= u>

On Mon, Aug 3, 2026 at 12:36=E2=80=AFPM Aaron Parecki <= aaron@parecki.com> wrote:

That's basically how we were thinking of it. I j= ust felt like it was something a bit out of scope of the ID-JAG spec. But t= he idea is very much to reuse the existing relationship established between= the Resource AS and IdP for ID-JAGs, and reuse it for workloads as well.

On Mon, Aug 3, 2026 at 12:33=E2=80=AFPM Karl McGuinness <me@karlmcguinness.com> wrote:

Paul,

Interesting draft. I'll have to dive in deeper. My initial reaction = is that this draft lines up with something I raised in ID-JAG issue #73 (https://github.com/oauth-wg/oauth-identity-assertion-= authz-grant/issues/73): whether ID-JAG should also cover workloads acting as themselves. The issue= sketches Workload and Agent Identity SSO modes where the assertion's s= ub is the workload or agent itself rather than a chained user identity, whi= ch is the same shape as your grant. The appeal of reusing ID-JAG was one simple SSO model for agents, workload= s, and clients, whether acting on behalf of a user or as themselves, and it= stays aligned with the standard identity and authorization claims (which a= lso bears on your question 2).

The deployment I was picturing looks a lot like the Enterprise IdP varia= nt in your issuer-placement open issue: the workload brings its credential = to the IdP (a WIMSE WIT, say), the IdP issues the grant, and the platform picks it up by token exchange. If t= he resource AS is already integrated with the IdP, things get simpler, sinc= e the IdP is already handling agent lifecycle, entitlements, and governance= through SCIM or JIT. The resource AS ends up with one federation relationship instead of an allowlist entry = per platform.

Would love to hear your thoughts, as there was some initial positive sig= nal on #73 but I was hoping for a larger discussion on the topic.=

Karl

On Mon, Aug 3, 2026 at 11:06=E2=80=AFAM Paul Carleton <paulc=3D40anthropic.com@dmarc.ietf.org> wrote:=

Hi all,

Good to meet many of you in Vienna!

I've posted an early individual draft based on some discussions had ove= r that week. The draft profiles RFC 7523 for agent platforms: an agent obta= ins access tokens by presenting a platform-signed JWT authorization grant a= t the resource's authorization server. I've also posted this to wimse@, since the identity in the grant is a = WIMSE workload identity produced by ordinary WIMSE issuance and cross-domai= n federation; this draft covers the OAuth-facing hop where an existing AS c= onsumes it.

This defines no new grant type, no new token format, and no change to RS-to= -AS trust. A service with an existing OAuth deployment changes only its tok= en endpoint. Trust is one admin-level entry per customer tenancy with keys = resolved by reference, and the AS accepts previously-unseen subjects under a trusted issuer just in time; th= ere is no client registration step.

Relative to adjacent work: same JWT-authorization-grant shape as ID-JAG and= draft-ietf-oauth-identity-chaining, but the subject is the agent workload = itself rather than a chained user identity. The agent-as-client alternative= (spiffe-client-auth, attestation-based-client-auth, CIMD) is addressed in question 1 below.

Datatracker: https://datatracker.ietf.org/doc/draft-carleton-workload-authz-grant/ Editor's copy: https://pcarleton.github.io/draft-carleton-workload-authz-grant/draft-carle= ton-workload-authz-grant.html
Repo: https://github.com/pcarleton/draft-carleton-workload-authz-grant

Feedback I'm most looking for:

1. The draft treats the agent as the grant subject, not a new client ID per= -instance, and I think that's the right shape; thank you Brian Campbell= for nudging me in that direction. It's one concrete stance in the ongo= ing client-instance discussion: consistent with the adopted stack (ATTEST, spiffe-client-auth, and the McGuinness dra= fts all keep one logical client_id and surface the instance elsewhere), and= it keeps the adoption floor at "jwt-bearer, which already ships every= where." Additional support for that framing would be helpful, or for concrete scenarios where subject-not-client break= s down.

2. Claim naming for platform-asserted attributes: reuse the RFC 9068 roles/= groups/entitlements registrations, or register new names? (Related question= posed to wimse@ about whether the AIMS work wants to own this vocabulary.)=

3. Input on Audience handling relative to rfc7523bis.

Requested cluster: Cross-Domain Chaining. Related: Client Authentication.
Most sections are deliberately TODO. Feedback here or on the repo is welcom= e.

Paul

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

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

This message and any attachment ("the Message") are confidential.= If you have received the Message in error, please notify the sender immedi= ately and delete the Message from your system, any use of the Message is fo= rbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding st= atements via e-mail unless explicitly agreed otherwise. Information pursuan= t to =C2=A7 14 Austrian Companies Code: Raiffeisen Bank International AG; R= egistered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Cou= rt of Vienna (Handelsgericht Wien).

--0000000000008a78750658465585--