# WIMSE (Workload Identity in Multi-System Environments)

Source: https://startwithidentity.com/standards/wimse/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

## What it is

WIMSE is the [IETF working group](https://datatracker.ietf.org/wg/wimse/about/) 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](https://startwithidentity.com/glossary/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](https://startwithidentity.com/experts/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](https://startwithidentity.com/glossary/wimse/) has the one-paragraph definition.

## Status (5 November 2026)

None of the WIMSE documents is an RFC. From the [WIMSE documents page](https://datatracker.ietf.org/wg/wimse/documents/):

| Draft | Rev, date | What it defines | State |
| --- | --- | --- | --- |
| [draft-ietf-wimse-http-signature](https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/) | -08, 20 Oct 2026 | Workload-to-workload authentication with HTTP Message Signatures | Publication Requested; submitted to IESG as Proposed Standard |
| [draft-ietf-wimse-workload-identity-practices](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-practices/) | -08, 30 Oct 2026 | Survey of current practice (Kubernetes, cloud, SPIFFE, CI/CD, meshes) | In Last Call, ends 13 Nov 2026; Informational |
| [draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) | -08, 6 Jul 2026 | Architecture | WG Document; Informational |
| [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/) | -04, 23 Oct 2026 | Workload Identifier URI | WG Document; Standards Track |
| [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/) | -03, 30 Oct 2026 | Workload Identity Token (WIT) and Certificate (WIC) | WG Document; Standards Track |
| [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) | -02, 27 Aug 2026 | Workload Proof Token | WG Document; Standards Track |
| [draft-ietf-wimse-mutual-tls](https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/) | -03, 24 Oct 2026 | Workload authentication over mutual TLS | WG Document |
| [draft-ietf-wimse-aims](https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/) | -01, 2 Nov 2026 | AI Identity Management System | WG Document; Informational |

The original service-to-service protocol, [draft-ietf-wimse-s2s-protocol](https://datatracker.ietf.org/doc/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](https://www.rfc-editor.org/rfc/rfc9421.html), `@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](https://startwithidentity.com/standards/oauth-transaction-tokens/) 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

| Need | Standard |
| --- | --- |
| Workload proves who it is to another workload | WIMSE credentials plus HTTP signatures, WPT or mTLS |
| Carry the user and request context through internal hops | [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/), bound into a WPT with `tth` |
| Workload calls an OAuth-protected API | [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) client credentials or [token exchange](https://startwithidentity.com/glossary/token-exchange/) (RFC 8693) |
| Agent acts for a user across apps | [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) |
| Revoke or react to compromise | [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/) |

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](https://startwithidentity.com/techniques/token-replay-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](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/) and [static API key abuse](https://startwithidentity.com/techniques/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](https://startwithidentity.com/vendors/zero-trust/palo-alto/)), Yaroslav Rosomakho ([Zscaler](https://startwithidentity.com/vendors/zero-trust/zscaler/)), [Brian Campbell](https://startwithidentity.com/experts/brian-campbell/) ([Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/)), Arndt Schwenkschuster and Pieter Kasselman ([Defakto (formerly SPIRL)](https://startwithidentity.com/vendors/machine-identity/spirl/)), Yaron Sheffer, and [Hannes Tschofenig](https://startwithidentity.com/experts/hannes-tschofenig/) on the architecture. The AIMS draft adds Jeff Lombardo (AWS), Nick Steele (OpenAI) and [Aaron Parecki](https://startwithidentity.com/experts/aaron-parecki/) ([Okta](https://startwithidentity.com/vendors/iam/okta/)). Authorship is not product support: no vendor has shipped a final WIMSE standard because none exists yet. The open source [SPIFFE / SPIRE](https://startwithidentity.com/vendors/machine-identity/spiffe-spire/) project is the closest deployed relative, and workload identity vendors such as [Aembit](https://startwithidentity.com/vendors/ai-identity/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](https://startwithidentity.com/guides/machine-identity/workload-identity-101/), [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/), [Kubernetes identity security](https://startwithidentity.com/guides/machine-identity/kubernetes-identity-security-guide/), [what is a non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/). Report: [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/). Glossary: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [SPIFFE](https://startwithidentity.com/glossary/spiffe/), [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/), [mTLS](https://startwithidentity.com/glossary/mtls/), [proof of possession](https://startwithidentity.com/glossary/proof-of-possession/), [NHI](https://startwithidentity.com/glossary/nhi/).