Skip to content

WIMSE Workload Proof Token (WPT) + Workload Credentials + HTTP Signatures — draft-ietf-wimse-wpt, draft-ietf-wimse-workload-creds, draft-ietf-wimse-http-signature#

IETF 123 (Madrid) digest Program Core pick Madrid · 19–25 July 2025

  • Tier: Core
  • Why: This trio is the concrete proof-of-possession machinery under the architecture, and it's the part that touches implementations: a credential format, a way to prove you hold the key, and an HTTP-signature option for when TLS isn't end-to-end. If you're evaluating workload-identity tooling, these define the interop surface.
  • What: workload-creds defines the credential a workload uses to represent its identity (usable in X.509 or token form), deliberately separated from the PoP mechanism. wpt defines the Workload Proof Token — a signed JWT binding authentication to a specific HTTP request, providing application-level proof of possession of the key behind a Workload Identity Token (WIT). http-signature defines an HTTP Signatures–based authentication option that gives end-to-end request (and optionally response) protection even through TLS proxies and load balancers. (from abstract only)
  • How: Credentials and proof-of-possession are split into separate documents so the same credential can be proven in different ways; WPT binds to the request to resist replay; the HTTP-signature variant protects requests across intermediaries that would otherwise break end-to-end mTLS.
  • Where applicable: General. The HTTP-signature path is HTTP-only but specifically useful where you have L7 proxies/LBs in the path — i.e. most real service meshes and API gateways.