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]
