This is a solid draft. glad to see it building on SPIFFE/WIMSE and OAuth rather than inventing new identity primitives. The "agents are workloads" framing in Section 3 is exactly right and should settle the debate about whether agents need their own identity model.
The Transaction Token pattern (Section 10.4) is particularly important. We arrived at something similar — short-lived ES256-signed tokens scoped to a single task with a 60s TTL, encoding the specific tools and operations authorized. The key addition we found necessary: embedding data classification and governance evidence in the token itself, so the token isn't just authorization ("you may call this tool") but also proof that scanning and policy evaluation happened. Makes the audit trail self-verifying.
One gap I'd flag: the draft covers the auth layer thoroughly but doesn't address the data protection layer: what happens to the content flowing through these authenticated channels. An agent can be
perfectly authenticated and authorized to call an LLM, and still send PII or credentials in the prompt. That's a different control plane (content scanning, classification, taint tracking) that sits
alongside auth, not inside it. Might be worth a forward reference to indicate this is complementary scope.
The static API keys antipattern callout in Section 6 is important. In practice, most agent deployments today still use long-lived API keys passed as environment variables. The gap between what this draft recommends and what people actually do is enormous.
There are two elements here. Agent can start a full authorization request with AS through authorization code grant flow, even requiring a step-up or some rich authorization details, therefore whatever OTP by SMS or Magic link is an AS - Subject/Client "problem".
For Agent that cannot start a full authorization request (too costly, to complex, subject directly unreachable at the moment), we have a mention to OpenID Connect CIBA into it. With it, the Agent will start a back channel authorization request with the AS and the AS will use a method of authentication / confirmation with the subject in front channel, for example sending a SMS or sending a link to click. Again the resolution will remain an AS - Subject/Client "problem".
The Transaction Token pattern (Section 10.4) is particularly important. We arrived at something similar — short-lived ES256-signed tokens scoped to a single task with a 60s TTL, encoding the specific tools and operations authorized. The key addition we found necessary: embedding data classification and governance evidence in the token itself, so the token isn't just authorization ("you may call this tool") but also proof that scanning and policy evaluation happened. Makes the audit trail self-verifying.
One gap I'd flag: the draft covers the auth layer thoroughly but doesn't address the data protection layer: what happens to the content flowing through these authenticated channels. An agent can be perfectly authenticated and authorized to call an LLM, and still send PII or credentials in the prompt. That's a different control plane (content scanning, classification, taint tracking) that sits alongside auth, not inside it. Might be worth a forward reference to indicate this is complementary scope.
The static API keys antipattern callout in Section 6 is important. In practice, most agent deployments today still use long-lived API keys passed as environment variables. The gap between what this draft recommends and what people actually do is enormous.