IETF · 6 July 2026
draft-ietf-wimse-arch-08
J. Salowey, Y. Rosomakho, H. Tschofenig
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
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.
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.