+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 to 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 PM Aaron Parecki <[email protected]> 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-authz-grant-04.html#appendix-A.2 > but imagine the case where the "CIAM Platform" in that example is actually > 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" role > 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 PM Paul Carleton <[email protected]> wrote: > >> >> Karl, I agree that shape sounds a lot 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 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 to 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. There >> is no expectation that Kubernetes clusters register their pod identities >> 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 deployment model, but I want to allow for >> 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. With >> 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 relevant >> to ID-JAG JIT provisioning. >> >> Yaron -- thanks for this. I agree we want PoP constraining. Re: OAuth >> SPIFFE Client Authentication >> <https://www.ietf.org/archive/id/draft-ietf-oauth-spiffe-client-auth-02.html>, >> I have sketched out the shapes here >> <https://pcarleton.github.io/draft-carleton-workload-authz-grant/request-shapes.html>. >> 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 towards >> CIMD + private_key_jwt for this particular pattern. >> >> On Mon, Aug 3, 2026 at 5:20 PM Yaron ZEHAVI <yaron.zehavi= >> [email protected]> wrote: >> >>> Hello everyone, >>> >>> >>> >>> This looks like a useful addition to OAuth SPIFFE Client Authentication >>> <https://www.ietf.org/archive/id/draft-ietf-oauth-spiffe-client-auth-02.html>, >>> which also uses workload identity as RFC7521/3 assertion JWTs, but stops >>> short of using them as JAGs, rather focuses on client authentication for >>> other grants. >>> >>> >>> >>> A couple remarks: >>> >>> - This draft feels more naturally positioned as another profile of >>> identity >>> chaining >>> >>> <https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-17.html>, >>> alongside ID JAG >>> >>> <https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html>. >>> The latter originates from challenges of streamlining cross-domain SSO >>> for >>> humans by removing friction, and now tackles further aspects in this >>> space >>> such as required claims for JIT user provisioning, deferred responses >>> etc. >>> - The JAG should be PoP constrained, which is easily achievable by >>> including the agent’s cnf claim in it. This mechanism is proposed by >>> OAuth >>> 2.0 JWT Authorization Grant with DPoP Binding >>> >>> <https://www.ietf.org/archive/id/draft-parecki-oauth-jwt-dpop-grant-01.html> >>> and we use it with good results in applicable JAG flows in our company. >>> >>> >>> >>> Yaron >>> >>> >>> >>> >>> >>> Classification: GENERAL >>> >>> *From:* Karl McGuinness <[email protected]> >>> *Sent:* Monday, August 3, 2026 9:47 PM >>> *To:* Aaron Parecki <[email protected]> >>> *Cc:* Paul Carleton <[email protected]>; >>> [email protected] >>> *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 as >>> a principal managed by the IdP across domains which 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 think of ID-JAG as SSO where the upstream IdP >>> 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 >>> shared which is why I was hoping to get more attention on the issue. >>> >>> >>> >>> On Mon, Aug 3, 2026 at 12:36 PM Aaron Parecki <[email protected]> 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 PM Karl McGuinness <[email protected]> >>> 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 sub is >>> the workload or agent itself rather than a chained user identity, which is >>> the same shape as your grant. The appeal of reusing ID-JAG was one simple >>> 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, and 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 AM Paul Carleton <paulc= >>> [email protected]> 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 agent >>> obtains access tokens by presenting a platform-signed JWT authorization >>> 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 only >>> its token 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; there 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-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 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 ongoing >>> 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 adoption >>> floor at "jwt-bearer, which already ships everywhere." Additional support >>> 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? (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 >>> welcome. >>> >>> Paul >>> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> 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 Message 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 § 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). >>> >>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
