Hi Paul, Your question 1 asks whether the agent should be the subject of a grant the Platform signs, rather than each agent instance being its own OAuth client. We think subject is right, and here is our "additional support for that framing." An agent on its own is not an identity. We treat online identity as actor × platform × conditions — all three, and a verifier should be checking all three. A workload on an untrusted platform, in an unknown security posture, should not be given access. So the Platform is not just a convenient place to put the signature: it is one of the three things being identified, and it is the only party that can see all three. That is why the signature belongs to it. The same holds when the actor is a person rather than an Agent.
This has a consequence for your Section 5. If the agent is only a subject and never a client, the authorization server never authenticates the agent at all — so proof of possession has to come from the Platform. We think that is the right place for it: the agent is short-lived and holds nothing, while the Platform persists and can hold a key To my understanding the question in Section 5 is: is the identity verified, now, so that access can be granted? And the question in Section 10 is: assuming it was, has the Agent been retired since? Neither the assertion nor the access token can answer either question. Your Section 5 option of sender-constrained access tokens — in practice DPoP or 8705 — is the right mechanism. It works by binding to a key. Now, if that key is no longer available * when the condition is no longer met — the workload detects an anomaly, say — * or when the job is done and the Agent is retired, then both Section 5 and Section 10 are addressed. That is what we have: a key that signs only while stated conditions are true, checked by the machine holding it at the moment it signs. Nothing is sent and nothing is revoked. The mechanism looks similar to 8705 or DPoP — a key, a signature per mTLS handshake or per request — but the key stands for the identity itself: it can sign only while actor, platform and conditions all hold, so checking the signature is checking the identity, not checking a binding to something established before. The conditions can be your Properties, with one added feature: the identity is verified now, at the point of access. If the conditions are not met, the key — the identity — is gone. Put that under your design and the residual access in your Section 10 goes away on both counts. It is best with a hardware root of trust, so it will not fit everywhere. And it covers only conditions the Platform can observe about itself; an Agent retired by a decision taken in another system still needs a signal to arrive, which is your event-push option. It shrinks that gap rather than closing it. This is written up in draft-winmagic-oauth-condition-bound-keys-00, which is about the key underneath 8705 and DPoP, and as a credential profile in draft-winmagic-wimse-condition-bounded-credentials-01. We think this is a good fit where the environment allows it, and I would like the group's view on it. On your other two questions: nothing useful from us on audience handling. On claim naming, I have replied on wimse@ — it is the credential side of the same point. Cheers Thi Nguyen-Huu | CEO Tel: +1 905.502.7000 x 3288 | Toll Free: 888.879.5879 [email protected]<mailto:[email protected]> | www.winmagic.com<http://www.winmagic.com/> WinMagic Corp. | 11-80 Galaxy Blvd. Toronto, ON | M9W 4Y8 | Canada | www.winmagic.com<http://www.winmagic.com/> From: Paul Carleton <[email protected]> Sent: Monday, August 3, 2026 2:05 PM To: [email protected] Subject: [OAUTH-WG] New I-D: draft-carleton-workload-authz-grant (Workload Authorization Grant) You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe. 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]
