The IETF looked at the identity landscape—already drowning in three-letter acronyms—and said, “What we really need is a five-letter acronym that nobody wants to say out loud in a meeting.”
WIMSE. Say it. WIMSE. Now say it to your CISO with a straight face.
The IETF just published draft-klrc-aiagent-auth-00, a framework for AI agent authentication and authorization. The authors—from Defakto Security, AWS, Zscaler, and Ping Identity—are proposing: don’t reinvent the wheel. Use WIMSE, OAuth 2.0, and existing workload identity standards.
Decentralized Identifiers already do everything we need for agent identity—self-issued, cryptographically verifiable, portable across organizations, no trust domain federation required. The wheel exists. They’re reinventing it anyway.
What the Draft Proposes
The draft correctly identifies that “many efforts develop solutions in isolation, often reinventing existing mechanisms unaware of applicable prior art.” The irony is lost on them. The proposed stack includes:
- WIMSE Proof Tokens (WPTs—because the identity space needed another three-letter acronym) for application-layer authentication that survives TLS termination
- HTTP Message Signatures for end-to-end integrity
- OAuth 2.0 for delegation and authorization
- SPIFFE for workload identity
We half-heartedly supported SPIFFE for workload identity—it’s fine for what it does. Cryptographic identity for services within a trust domain. But SPIFFE was designed for microservices calling each other inside a controlled environment, not for autonomous agents negotiating across organizational boundaries.
And what exactly is a workload identity in WIMSE? A URI scoped to a trust domain:
spiffe://trust.example.com/ns/production/payment-service
wimse://corp.acme.com/workload/af3e86cb-7013-4e33-b717-11c4edd25679That’s it. A scheme, a trust domain, and a path. Identity only makes sense within a trust domain—two workloads with the same path but different trust domains are completely different identities. Cross-domain trust requires explicit federation between the domains.
This is fine for “microservices within my Kubernetes cluster” or “workloads across my AWS accounts.” It falls apart the moment an agent from Company A meets an agent from Company B for the first time.
On Message Signatures: We’ve Been Here Before
The one thing the draft gets right—HTTP Message Signatures for end-to-end integrity—is something we’ve been implementing for years. We wrote about this in Beyond SEO: How JSON-LD Can Prove Authenticity.
Here’s the thing: SOAP got this right two decades ago. WS-Security, XML Signatures, the whole nine yards. Cryptographic signatures at the message layer that survive TLS termination, proxies, load balancers, message queues. The enterprise world figured this out in 2002.
When we started building for agents, it was obvious they’d need the same thing. Agents don’t control the network path. Messages get queued, forwarded, transformed. TLS protects the pipe, not the message. You need signatures that travel with the payload.
So we implemented SOAP-style message signatures over JSON-LD. Canonicalization, detached signatures, the works. It wasn’t a breakthrough—it was table stakes. The fact that the IETF is now proposing this as novel infrastructure for AI agents suggests they haven’t been paying attention to what agent builders actually need.
And then there’s OAuth.
The Problem with OAuth for Agents
OAuth is a delegation protocol. Its entire mental model is: a human grants limited authority to an application to act on their behalf. The canonical flow involves a user clicking “Allow” in a browser, authorizing an app to access their Google Drive or GitHub repos.
This model breaks down completely for autonomous agents.
We wrote about this last year in Rethinking Agentic Trust: Why “Delegation” Might Be the Wrong Model. The core argument: delegation assumes authority is rooted in a person, and the protocol exists to extend that person’s identity into a system. But autonomous agents don’t work that way.
Consider a swarm of agents—tens or hundreds, spawned on demand, coordinating with each other to solve problems without direct human oversight. You don’t “delegate” to a swarm. You don’t hand over your OAuth token. Instead, agents need their own identity, their own credentials, their own trust relationships.
The IETF draft acknowledges this tension but doesn’t resolve it. It mentions “agent self-authorization” via Client Credentials grants—which is designed for M2M auth. But OAuth’s core abstractions (authorization servers, scopes, token introspection) still assume a centralized trust anchor. An agent’s identity only makes sense within the scope of a single authorization server. Cross-domain agent collaboration requires federation, and federation requires prior agreements between organizations.
Delegation vs. Hiring
A better mental model is hiring, not delegation. You don’t hand an agent your credentials and say “act as me.” Instead, you evaluate the agent’s capabilities, verify its attestations, and establish a contractual arrangement that defines the scope of its authority.
This shift matters because it changes what identity infrastructure needs to provide:
| Delegation Model | Hiring Model |
|---|---|
| Authority flows from human identity | Agents have their own identity |
| OAuth tokens encode human permissions | Agents carry verifiable credentials |
| Trust is binary (delegated or not) | Trust is evaluated contextually |
| Single human → single agent | Agent swarms, A2A collaboration |
Needless to say, the IETF draft is firmly in the delegation column.
The DID-Shaped Hole
Notably absent from the draft: Decentralized Identifiers (DIDs).
The framework relies on X.509 certificates and OAuth client credentials—both of which require centralized issuance. That works fine within a single organization or cloud provider. But what about:
- An agent from Company A negotiating with an agent from Company B?
- A supply chain where agents need to verify the provenance of artifacts across organizational boundaries?
- A marketplace where agents from unknown parties need to establish trust dynamically?
DIDs solve the “how do I verify identity across organizational boundaries without a shared certificate authority” problem. They’re already seeing adoption in supply chain security (SLSA, in-toto attestations) and content authenticity (C2PA). The fact that this draft doesn’t mention them suggests the authors are thinking primarily about internal workloads, not cross-organizational agent collaboration.
What’s Missing: The Trust Layer
The draft focuses almost entirely on authentication—proving that an agent is who it claims to be. But it barely touches trust—deciding whether you should collaborate with that agent at all.
Authentication answers: “Is this really Agent X?”
Trust answers: “Should I give Agent X access to my customer data?”
These are different questions. Like most agent authentication projects out there, the draft punts on trust. Similar to C2PA, it assumes that trust roots are provisioned… somewhere. But agentic workloads are a total mismatch with the certificate authority model. The draft defers to “policy and compliance functions” without specifying how those policies get informed.
In practice, this means the framework assumes you already know which agents to trust. But in a world of autonomous agents from different organizations, that assumption breaks down fast.
Where Provenance Fits In
There’s another gap: the draft doesn’t address what agents do, only who they are.
Consider a code-signing agent that generates SBOMs and attestations. Authentication tells you the agent is legitimate. But it doesn’t tell you:
- What artifacts the agent has processed
- What attestations it has generated
- Whether those attestations are trustworthy
- What policies governed its actions
Agent identity is necessary but not sufficient. You also need provenance about what the agent produces—which is exactly what C2PA and in-toto provide.
Our Take
This IETF draft is a starting point, not a solution. It consolidates existing standards—but those standards were designed for a different era. OAuth is a delegation protocol for human-initiated flows. SPIFFE is workload identity for controlled environments. Neither was designed for autonomous agents collaborating across organizational boundaries.
For the agentic future we’re heading toward, we need:
- Agents with their own identity, not borrowed human credentials
- Decentralized identity (DIDs) for cross-organizational verification
- Trust graphs that encode organizational relationships and attestation capabilities
- Provenance tracking for agent outputs, not just agent authentication
- A hiring model, not a delegation model
We’re building this trust layer at Noosphere. The IETF draft handles authentication plumbing—who the agent claims to be. We’re focused on the harder questions: Should you trust this agent? And should you trust what it produces?
The draft is at datatracker.ietf.org/doc/draft-klrc-aiagent-auth/. It’s an individual submission, not yet adopted by any IETF working group. Comments are welcome—this is exactly the kind of standards work that benefits from broad input.