IETF · 6 July 2026
draft-ietf-wimse-arch-08
J. Salowey, Y. Rosomakho, H. Tschofenig
Workload Identity in a Multi System Environment (WIMSE) Architecture (draft-ietf-wimse-arch-08) is WG draft, 6 July 2026. If the agent is a workload in your mesh, WIMSE/SPIFFE is its identity. OAuth then answers what it may do for a user. Mixing those layers is how you get both 'which binary called us' and 'which customer they were serving'.
At a glance
Actors
Animated sequence · WIMSE
Each hop re-binds
WIT names the workload (the binary), not the user. WPT is bound to this hop. The next hop must re-bind with a new WPT — it does not replay the previous workload's identity. User context travels in another header (Txn-Token / OAuth).
Now · 1/7· Discover· WIMSEYou are here
SPIRE / issuer→Workload A·Issues WIT (workload identity token). sub is the binary, not a user
WIT names A. The issuer (often SPIRE) also provides the key material used to mint WPTs. This is not a user sub.
Why Workload identity answers which service in which trust domain — not which human. This credential is not an OAuth access token.
A badge for the machine, not a nametag for Alice.
Solid = from the spec
WIMSE architecture is a WG informational draft, not a protocol RFC. Implement WIT/WPT or SPIFFE for wire. Do not stuff the user into the SPIFFE ID. Nested act (RFC 8693) is a different chain. Credential, bind WPT to this hop, re-bind at the next hop.
In one board · hops
→ WIT + WPT (or mTLS) →
WIT names the binary (spiffe:// or wimse://). WPT or mTLS is the seal. Never put WIT in Authorization: Bearer — that would be a photocopy of a workload pass.
WIT sub = payment-api, not Alice
WIMSE architecture is a WG informational draft, not a protocol RFC. Implement WIT/WPT or SPIFFE for wire. Contrast with token exchange.
Sequence above; this list is the same hops for reading and search. Each row is one message.
SPIRE / issuer→Workload AWIMSEIssues WIT (workload identity token). sub is the binary, not a user
Workload A→Workload AWIMSE WPTMints a WPT bound to this hop (A → B)
Workload A→Workload BWIMSE WPTA authenticates to B with WIT + WPT (or mTLS)
SPIRE / issuer→Workload BWIMSEB already has (or now receives) its own WIT — A's identity is not forwarded
Workload B→Workload BWIMSE WPTMints a new WPT bound to the next hop (B → C)
Workload B→Workload CWIMSEB authenticates as itself with B's WIT + the new WPT
Workload C→Workload BWIMSEC verifies this hop's WPT and responds
01
Software executing as workloads — including AI intermediaries — needs identifiers, credentials, and security-context propagation across clouds, meshes, and administrative domains. SPIFFE solved much of this inside one trust domain; WIMSE aims at the multi-system case.
Section 3.4.11 of draft-ietf-wimse-arch-08 (6 July 2026) is explicit: agentic AI systems are a special case of delegated workloads. They inherit an upstream principal's security context and MUST NOT silently widen it. Agent-to-agent hops MUST re-bind and scope context at each hop or a chain of AI-to-AI interactions can extend authority far beyond what was originally granted.
If the agent is a workload in your mesh, WIMSE/SPIFFE is its identity. OAuth then answers what it may do for a user. AAuth argues WIMSE/SPIFFE do not help an agent across org boundaries without extra work — both views are about different deployment scopes.
02
A workload identifier is unique within a trust domain. Trust anchors for that domain are distributed out of band — you do not fetch them from a URL found only inside a token. Identity servers issue credentials. Relying workloads verify. Upstream principals (users or services) are a different name; stuffing the user into the workload URI collapses the architecture.
AI intermediaries act as both delegated workload and, when they call other agents, as delegators. Each hop is a trust-boundary crossing even inside one cluster.
03
Informational WG architecture, not a protocol RFC. A workload is provisioned with a Workload Identifier and credentials (WIT and/or WIC). It authenticates to peers with mTLS, WPT, or HTTP Message Signatures. When acting as a delegate, it propagates upstream security context (Txn-Tokens, OAuth tokens in their own headers) and re-binds/scopes it at each hop. Companion drafts: identifier, workload-creds, WPT.
04
Flow 1
Platform/agent attests the workload to an identity server (SPIRE-like or otherwise).
Workload receives WIT and/or WIC bound to one identifier and a key.
Calling a peer: mTLS with WIC, or WIT + WPT, or WIT + HTTP signatures. Never WIT as bearer.
If serving a user: also propagate OAuth/Txn-Token context in its own header. Re-scope before calling another agent.
05
Primarily identity of the workload, plus how authentication protocols and authorization context (including delegation) should compose. Authorization decisions remain policy/OAuth/AAP. User identity remains OIDC/sub in a context token.
06
WIT/WIC formats.
Application-layer PoP for WIT.
Production-proven subset WIMSE generalizes.
User/delegation layer beside workload identity.
Immutable purpose across hops inside a domain.
Open-world HTTP identity vs multi-system workload identity. An agent can hold both.
AIMS tells you to use WIMSE for agent-as-workload authentication.
07
The architecture's AI section is a warning, not optional colour. Re-bind context every hop.
One identifier per credential. Alice is not a workload path.
Forbidden by the credential draft. If you put WIT in Authorization: Bearer you have undone PoP.
08
draft-ietf-wimse-arch-08, 6 July 2026, expires 7 January 2027, informational WG architecture. Authors: J. Salowey, Y. Rosomakho, H. Tschofenig. https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/. Use it as a design map; implement the credential/WPT drafts and/or SPIFFE for wire.
WG informational architecture, not a protocol RFC yet. Section 3.4.11 (AI and ML-based intermediaries) is the paragraph to quote when someone asks 'does WIMSE cover agents?'. AAuth's own draft argues WIMSE/SPIFFE do not help an agent across org boundaries without extra work — both views are about different deployment scopes.