No explainer written for this spec yet. The summary, relations and documented support below are maintained.
A per-request signed JWT that proves possession of the key in a Workload Identity Token, bound to the target and message.
A per-request signed JWT that proves possession of the key in a Workload Identity Token, bound to the target and message.
No explainer written for this spec yet. The summary, relations and documented support below are maintained.
A per-request signed JWT that proves possession of the key in a Workload Identity Token, bound to the target and message.
flowchart LR s_wpt["WIMSE Workload Proof Token"] s_wimse_creds["WIMSE Workload Credentials"] s_dpop["DPoP"] s_wimse_httpsig["WIMSE HTTP Message Signatures"] style s_wpt stroke-width:3px s_wpt -->|Builds on| s_wimse_creds s_wpt -.-|Alternative to| s_dpop s_wimse_httpsig -.-|Alternative to| s_wpt
Adoption lists only support stated in official documentation (the vendor's or project's own, or a standards body's page naming it), and a weekly check confirms the cited phrase is still on that page. Experimental, alpha and beta support is counted separately as preview.
No sourced support entries collected yet. This says nothing about how widely it is used.
Revisions from the Datatracker, explanations from this site's daily runs, and mailing-list subjects naming the draft.
Review of draft-ietf-wimse-wpt
The review is mostly editorial and reads the draft as a clear guide for implementers. It asks to break out the Key Characteristics paragraphs. From a security view it asks why the check that a jti has not been used before in the WPT validity window is RECOMMENDED rather than MUST. It also asks what collision resistant means for a claim such as example.com/myclaim, since the term usually refers to hash functions. No text change has been made.