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

[Karl McGuinness <[e-mail]>]

+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 <[e-mail]> 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 <[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).
>>>
>>