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

[Paul Carleton <[e-mail]>]

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