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]
