WIMSE is an active IETF working group in the Applications and Real-Time area, standardizing how a workload — a running process, container, function or AI agent — gets an identity, proves it, and carries it across trust boundaries at runtime. It produces an architecture document plus a stack of Proposed Standards covering the workload identifier, workload credentials, mutual TLS authentication, Workload Proof Tokens, and workload-to-workload authentication over HTTP Message Signatures. Its charter is deliberately narrow — runtime identity only, explicitly excluding personal identity, static software identity, deployment chains and supply-chain management.
WIMSE
WIMSE is the IETF’s answer to a question that used to be an infrastructure detail and is now an API contract question: when a call arrives, what is the caller — not the user behind it, the software making it. SPIFFE got there first and got there working; WIMSE is the effort to standardize the same model at the IETF, generalize it beyond one implementation, and specify the wire protocols that SPIFFE left to deployments. The architecture draft has been through eight revisions since April 2024 and nothing has reached RFC yet.
- Workload Identifier (
draft-ietf-wimse-identifier) - A URI naming a workload inside a trust domain. A SPIFFE ID is a conforming instance of it. - Workload Credentials (
draft-ietf-wimse-workload-creds) - Profiles of X.509 certificates and Workload Identity Tokens (WITs), the artifacts that cryptographically bind an identifier to a key. - Workload Proof Token (
draft-ietf-wimse-wpt) - A short-lived signed JWT proving possession of the key in a WIT, bound to a specific message context. Carriesaud,exp,jtiandwth— a hash of the associated WIT — and rides HTTP in aWorkload-Proof-Tokenheader. - HTTP Signatures profile (
draft-ietf-wimse-http-signature) - Combines a WIT with HTTP Message Signatures so identity survives proxies and load balancers that terminate TLS. Mandates signing method, request-target, content digest and the WIT. - Mutual TLS (
draft-ietf-wimse-mutual-tls) - The transport-layer option, for when the connection is the right place to authenticate. - Practices (
draft-ietf-wimse-workload-identity-practices) - The operational Informational document, and the furthest along: submitted to the IESG, sitting in AD Evaluation.
The reason WIMSE matters to an API catalog is that the IETF agent authentication and authorization
draft picks it as the spine: an AI agent is a workload, so it MUST be assigned
exactly one WIMSE identifier and MUST hold a credential cryptographically bound to it. That reframes a
pile of agent-identity startups as an implementation question about a specification that already exists.
It also sets a bar essentially nothing on the public API surface currently clears — scanning the API
Evangelist catalog in August 2026, thirteen providers declared mutualTLS in an OpenAPI at all, and
workload identity lives inside private service meshes rather than at anybody’s public edge. That gap is
the interesting part, not a failing: WIMSE was designed for east-west traffic, and whether it reaches
north-south API surfaces is exactly the open question the agent-auth draft forces.
