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 <[email protected]> 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= > [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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
