Flow · multi-hop
Workload identity plus user delegation
SPIFFE/WIMSE proves which agent binary is calling. OAuth proves which user it may act for. Both are required in production meshes.
Use the hop list beside the stage, or the phase labels, to jump. Every hop has Now, Why, the RFC, and chips — none are skipped.
Actors
SPIRE · Agent workload · OAuth AS · Tool
Sequence
Animated sequence · multi-hop
WIMSE + OAuth — Who is calling at this hop — the binary, or the user?
Workload identity plus user delegation
SPIFFE/WIMSE proves which agent binary is calling. OAuth proves which user it may act for. Both are required in production meshes.
Now · 1/5· Discover· WIMSEYou are here
SPIRE→Agent workload·Issues X.509-SVID or WIT credential. sub is the binary, not a user
WIT (or an X.509-SVID) names the workload. sub is the binary, not a user sub.
Why Workload identity answers which binary in which trust domain — not which human.
A badge for the machine, not a nametag for Alice.
- WIT from the spec
- X.509-SVID from the spec
- sub=workload from the spec
Solid = from the spec
Do not stuff the user into the SPIFFE ID. Do not skip workload identity because you have an OAuth token — a stolen user token presented by a different binary is a different incident.
Transcript
- 1
DiscoverSPIRE→Agent workloadWIMSE
Issues X.509-SVID or WIT credential. sub is the binary, not a user
WIT (or an X.509-SVID) names the workload. sub is the binary, not a user sub.
Why Workload identity answers which binary in which trust domain — not which human.
A badge for the machine, not a nametag for Alice.
- WIT
- X.509-SVID
- sub=workload
- 2
ProveAgent workload→Agent workloadWIMSE WPT
Mints a WPT bound to this hop (workload → OAuth AS or tool)
The workload creates a proof token bound to the next hop. User context is a different ticket.
Why Do not skip the bind. Never put WIT in Authorization: Bearer. WPT (or mTLS) is the proof for this hop.
Glue this hop's wax to the machine badge.
- WPT
- this hop
- 3
GrantAgent workload→OAuth ASOAuth 2.1
Client authentication via SPIFFE (or mTLS RFC 8705) + user grant
SPIFFE client auth (or mTLS) proves the workload. The user grant is a separate OAuth/OIDC ticket (authorization code + PKCE, or CIBA).
Why The AS should know which binary is asking, then mint a user-delegated pass. Do not put the user into the SPIFFE ID.
Show the machine badge at the OAuth desk, then collect Alice's pass.
- SPIFFE client auth
- mTLS
- authorization code / CIBA
- 4
CallAgent workload→ToolWIMSE
Presents WIT+WPT (this hop) + access token or Txn-Token (user)
Workload proof is bound to this hop. User context rides in another header. Never Authorization: Bearer with a WIT.
Why Two proofs on one call. A stolen user token presented by a different binary is a different incident. Workload proof re-binds at this hop.
Wax seal of this binary, plus Alice's pass as a second paper.
- WIT / WPT
- mTLS
- access token
- Txn-Token
- 5
CallAgent workload→ToolWIMSE
Next hop: mint a new WPT bound to that hop — do not forward the last WPT
If this workload calls onward, it authenticates as itself with a new WPT. A's identity is not forwarded.
Why Each hop re-binds. Forwarding the previous WPT (or WIT as Bearer) would let the chain silently widen. Nested act (RFC 8693) is a different chain.
New wax for the next doorway. Tear off the last hop's glue.
- WPT
- hop re-bind
- not user sub
Caveats
Do not stuff the user into the SPIFFE ID. Do not skip workload identity because you have an OAuth token — a stolen user token presented by a different binary is a different incident.