IETF · 2 July 2026

WIMSE Workload Credentials

draft-ietf-wimse-workload-creds-02

WG draftDraft — expect changeIdentityAgent-specificField guide

This is the 'agent identity document' in the WIMSE world, analogous to AAuth's agent token but scoped to workload trust domains.

At a glance

Problem: Bind a public key to a workload identifier in a credential that must not be used as a bearer token.
Identity / authn / authz: Identity credential. Proof-of-possession is specified in companion drafts (WPT, HTTP signature, mTLS).

Actors

Identity server
Workload
Relying party

The gap for agents

Bind a public key to a workload identifier in a credential that must not be used as a bearer token. This is the 'agent identity document' in the WIMSE world, analogous to AAuth's agent token but scoped to workload trust domains that share configured trust anchors.

Actors and trust boundaries

Trust anchors for a trust domain are configured out of band. The iss claim MUST NOT be used to look up trust anchors from information carried only in the token (no 'fetch JWKS from whatever iss says'). Validators use the trust domain in sub. That is stricter than typical OAuth AS JWKS discovery — on purpose.

Mechanics

draft-ietf-wimse-workload-creds-02, 2 July 2026. Workload Identity Token: JWS JWT, typ wit+jwt, sub = identifier, exp (hours-scale), cnf.jwk with alg (ES256 MUST be supported; none and symmetric/encryption algs forbidden). Conveyed in Workload-Identity-Token header — not Authorization. Workload Identity Certificate: X.509 with a single URI SAN, SPIFFE-compatible. Authors include B. Campbell, J. Salowey, A. Schwenkschuster, Y. Sheffer, Y. Rosomakho.

typ: wit+jwtfrom spec: Quoted: explicit typing per RFC 8725.
cnf.jwk + algfrom spec: Quoted: public key of the workload. Proof of that key is mandatory. MUST NOT be used as a bearer token; not intended for Authorization.
Workload-Identity-Token headerfrom spec: Quoted HTTP field for presenting a WIT.
WIC (X.509)from spec: Quoted: transport-layer identity certificate; URI SAN.

Step-by-step flows

Flow 1

Issue and present a WIT

1
Identity server mints wit+jwt with sub, cnf.jwk, exp on the order of hours.
2
Workload presents Workload-Identity-Token plus a WPT (or HTTP signature) proving cnf.
3
Recipient validates against configured trust anchors for the trust domain in sub, then the proof.
4
On WIT validation failure, prefer HTTP 400 with problem details, not 401 Bearer — 401's WWW-Authenticate/Authorization pairing is not how WIT works.

Identity vs authentication vs authorization

Identity credential. Proof-of-possession is specified in companion drafts (WPT, HTTP signature, mTLS). Authorization context (Txn-Tokens, OAuth) rides in other headers.

How it composes

WIMSE WPT
Application-layer PoP.
SPIFFE / SPIRE
WIC aligns with X509-SVID practice.
JWT
WIT is a typed JWT profile.
Transaction Tokens
Explicitly allowed alongside WIT; different header.
AAuth
Similar 'JWT + key + not bearer' idea; different typ, discovery, and trust-anchor story.

What bites agent implementers

JWKS from iss
Forbidden as the sole trust source. Configure anchors per trust domain.
Authorization: Bearer WIT
The draft says not intended for Authorization and MUST NOT be used as bearer. Use WPT's Authorization: WPT scheme instead.

Stability — what you can ship

draft-ietf-wimse-workload-creds-02, 2 July 2026, expires 3 January 2027, standards-track WG. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02

Catalog claims (short form)

WIT (JWS JWT): Application-layer identity token; not bearer.
WIC (X.509): Transport-layer identity certificate; URI SAN.

Implementer notes

WIT in sub, WIC in a single URI SAN. Aligns with X509-SVID practice.

Relationship to others

Primary sources

HTML of draft-02https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02