WIMSE Workload-to-Workload Authentication with HTTP Signatures#

Joe Salowey (CyberArk), Yaron Sheffer (Intuit).

• Why: The application-layer leg of WIMSE — authentication that survives the TLS-terminating proxies and load balancers that dominate real service topologies, which the PM's mesh/ingress world knows well.
• What: WG draft -04 requesting WGLC. Two changes since -02: the audience indicator moved from a bespoke Wimse-Audience header to a wimse-aud HTTP Signatures parameter (still URI-shaped), letting a recipient confirm the signed message targets it; and a wimse-req-nonce parameter copies the request's random nonce into the signed response, closing a cut-and-paste attack where an on-path malicious proxy splices a valid response into the wrong request — RFC 9421 signs request and response but doesn't bind them.
• How: RFC 9421 signatures over the Workload Identity Token and request components; response signing optional but recommended given the assumed-malicious-proxy threat model.
• Where applicable: HTTP-based workload-to-workload traffic only (other protocols use other WIMSE proof mechanisms); needs updating of the draft's examples for the new parameters.