WIMSE (Workload Identity in Multi-System Environments)

What it is

WIMSE is the IETF working group standardizing how software workloads (services, jobs, functions, AI agents) identify and authenticate to each other at runtime, across clusters, clouds and organizations. Its drafts define four pieces: a workload identifier URI, two credential formats that bind a key to that identifier (a JWT and an X.509 certificate), proof of possession so a stolen credential cannot simply be replayed, and an architecture for carrying security context through call chains.

The charter scopes it to "the unique identity and access management aspects of workloads at runtime", building on OAuth, JWT and SPIFFE, and to "only specific REST-based technologies using HTTP." Static software identity and provenance (SBOMs), personal identities, deployment chains and supply chain management are out of scope. The working group sits in the Applications and Real-Time Area; the chairs are Justin Richer and Pieter Kasselman.

The short version for practitioners: WIMSE is trying to replace static API keys and long-lived shared secrets between services with short-lived, key-bound credentials that any environment can verify. The WIMSE glossary entry has the one-paragraph definition.

Status (5 November 2026)

None of the WIMSE documents is an RFC. From the WIMSE documents page:

The original service-to-service protocol, draft-ietf-wimse-s2s-protocol, stopped at -07 (16 October 2025) and is marked replaced by the workload-creds, http-signature, mutual-tls and wpt drafts. Older blog posts that cite "the WIMSE S2S draft" refer to that document.

The charter's milestones are behind schedule: the architecture was due to the IESG by 31 July 2026 and is still a working group draft. The datatracker also lists 20 related individual drafts, most about AI agent delegation; those have no working group standing.

How it works

The building blocks

• Trust domain. "A logical grouping of systems that share a common set of security controls and policies", named by a fully qualified domain name (architecture draft).
• Workload identifier. An absolute URI whose authority is the trust domain, with a non-empty path and no query, fragment, user info or port. The identifier draft defines wimse://<trust-domain>/<path>, for example wimse://trust.example.com/service/payment, and allows other schemes such as spiffe://. Consumers must compare the full normalized URI and must treat it as authenticated only when it came from a validated credential.
• Workload Identity Token (WIT). A JWS-signed JWT with typ wit+jwt (media type application/wit+jwt). Required claims: sub (one workload identifier), exp (refresh on the order of hours) and cnf with a jwk holding the workload's public key. iss is recommended, jti optional, alg: none forbidden, and ES256 must be supported. It travels in the Workload-Identity-Token HTTP header.
• Workload Identity Certificate (WIC). An X.509 certificate carrying exactly one workload identifier in a URI SubjectAltName, short-lived like a WIT, for mutual TLS.

The credentials draft is explicit that a WIT "MUST NOT be used as a bearer token." It always travels with a proof of possession.

A workload-to-workload call with HTTP signatures

1. The workload obtains a WIT from its trust domain's issuer, typically after attestation (the architecture aligns with RATS, RFC 9334, and cites SPIRE as an example of attestation-based provisioning).
2. For each request it signs, per RFC 9421, @method, @path and @query, plus Content-Type, Content-Digest, Authorization, Txn-Token and Workload-Identity-Token when present. @authority is deliberately not covered so proxies can rewrite it.
3. The signature parameters include created, a short expires, a nonce, tag set to wimse-workload-to-workload, and wimse-aud naming the intended recipient. keyid and alg must not be used; the algorithm comes from the WIT's cnf.jwk.alg.
4. The receiver validates the WIT against the trust anchors for its trust domain, then verifies the signature with the public key in cnf, then authorizes on the full workload identifier.
5. Optionally, the client sets wimse-sign-response and the server signs its response, echoing the request nonce in wimse-req-nonce.

The alternatives: Workload Proof Token and mTLS

The Workload Proof Token (WPT, typ wpt+jwt) is a per-request JWT signed with the WIT's key and sent as Authorization: WPT <token>. It carries aud (the target URI), a short exp, a 128-bit jti, and wth, the SHA-256 hash of the WIT. It can also bind other tokens on the request: tth for a Transaction Token and oth for others. Receivers should reject a reused jti within the validity window, and implementations must not log raw WPTs by default. Use the WPT when you want a token-shaped proof; use HTTP signatures when you want the request body and headers covered.

The mutual TLS draft profiles the WIC: exactly one URI SAN with a workload identifier, chain validation to the anchor configured for that trust domain, and authorization on the whole identifier, never the path alone. It is the natural fit for service meshes that already terminate mTLS in sidecars.

Where WIMSE fits with other standards

The architecture draft uses token exchange for delegation and impersonation, Transaction Tokens for context propagation, and OAuth identity chaining for cross-domain calls. WIMSE authenticates the caller; those documents carry what the caller is allowed to do and on whose behalf.

Common mistakes the drafts warn about

• Treating the WIT as a bearer token. Without the proof of possession, a logged or intercepted WIT is a replayable credential, which is the token replay at an unbound endpoint pattern.
• Authorizing on the path alone. /service/payment means nothing outside its trust domain; compare the whole identifier.
• Weak replay caches. The WPT draft notes that if replay caches are not shared across validators and an attacker can choose which validator receives a message, replay protection may fail.
• Secrets in environment variables. The practices draft recommends delivering credentials via the filesystem or a local API, using a distinct audience per target, and preferring proof-of-possession over bearer tokens. See secrets in repositories and CI and static API key abuse for what happens otherwise.

Who is building it

Draft authors, as listed on the datatracker, include Joseph Salowey (Palo Alto Networks), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Arndt Schwenkschuster and Pieter Kasselman (Defakto (formerly SPIRL)), Yaron Sheffer, and Hannes Tschofenig on the architecture. The AIMS draft adds Jeff Lombardo (AWS), Nick Steele (OpenAI) and Aaron Parecki (Okta). Authorship is not product support: no vendor has shipped a final WIMSE standard because none exists yet. The open source SPIFFE / SPIRE project is the closest deployed relative, and workload identity vendors such as Aembit solve the same problem today with their own mechanisms.

How to prepare

1. Inventory service-to-service credentials and flag every static API key and long-lived shared secret.
2. Adopt URI workload identifiers now (SPIFFE IDs work), named by trust domain.
3. Move to short-lived, key-bound credentials (SPIFFE SVIDs or cloud workload identity federation) delivered by a local API.
4. Keep authorization on the full identifier, and carry user context separately in Transaction Tokens.
5. Track the http-signature draft through the IESG; it is the first WIMSE protocol likely to become an RFC.

Related

Guides: workload identity 101, securing AI agent identities, Kubernetes identity security, what is a non-human identity. Report: Agent Identity Standards Map 2026. Glossary: workload identity, SPIFFE, workload identity federation, mTLS, proof of possession, NHI.