[OAUTH-WG] Re: New I-D: draft-carleton-workload-authz-grant (Workload Authorization Grant)

[Aaron Parecki <[e-mail]>]

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 <[e-mail]> 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=
> [e-mail]> 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 <[e-mail]>
>> *Sent:* Monday, August 3, 2026 9:47 PM
>> *To:* Aaron Parecki <[e-mail]>
>> *Cc:* Paul Carleton <paulc=[e-mail]>;
>> [e-mail]
>> *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 <[e-mail]> 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 <[e-mail]>
>> 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=
>> [e-mail]> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> 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).
>>
>