Identity Deep Dive

WIMSE Workload Credentials

Defines the Workload Identity Token (a JWT) and the Workload Identity Certificate (X.509) that bind a key to a workload identifier.

Where it stands
Working-group draft
Official text
draft-ietf-wimse-workload-creds-03
2026-10-30
Documented support
2
Activity
4 signals in 90 days

Deep dive

No explainer written for this spec yet. The summary, relations and documented support below are maintained.

Defines the Workload Identity Token (a JWT) and the Workload Identity Certificate (X.509) that bind a key to a workload identifier.

How it relates to other specs

Relations diagram
flowchart LR
  s_wimse_creds["WIMSE Workload Credentials"]
  s_wimse_arch["WIMSE Architecture"]
  s_jwt["JSON Web Token"]
  s_wpt["WIMSE Workload Proof Token"]
  s_wimse_httpsig["WIMSE HTTP Message Signatures"]
  s_wimse_mtls["WIMSE Mutual TLS"]
  style s_wimse_creds stroke-width:3px
  s_wimse_creds -->|Builds on| s_wimse_arch
  s_wimse_creds -->|Builds on| s_jwt
  s_wpt -->|Builds on| s_wimse_creds
  s_wimse_httpsig -->|Builds on| s_wimse_creds
  s_wimse_mtls -->|Builds on| s_wimse_creds

Documented support

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.

Products, identity providers and services

  • SPIFFE (Specification): The WIT-SVID spec defines every WIT-SVID as a WIMSE Workload Identity Token source (verified 2026-11-11)
  • Solo.io (Istio 1.30.x ambient) (Product)alpha: Solo's Istio ambient distribution supports WIMSE workload identity tokens as an alpha feature source (verified 2026-11-11)

Activity

Revisions from the Datatracker, explanations from this site's daily runs, and mailing-list subjects naming the draft.

Explanations on this site

  • DiscussionIETF WIMSE

    A reviewer suggests mostly readability edits to workload-creds, plus questions on exp lifetime, deny-list wording and mTLS in Section 9.6.

    Review of draft-ietf-wimse-workload-creds

    Read the explanation

    The reviewer proposes rewording the abstract so credentials are 'bound to' the workload identity rather than 'represent' it. They also propose restating the WIT (application layer, e.g. HTTP) versus WIC (transport layer, mTLS) split as two recommended patterns, with a rationale. For Section 5 they suggest explaining why TLS termination at a load balancer calls for an application-layer credential that stays unaltered. On Section 5.1 they ask whether the 'hours' guidance for exp should be shorter, since some deployments already use about 5 minutes, and why jti text says deny-list rather than allow-list. They suggest Section 9.2 mention that short exp values mitigate the problem it describes. The one normative edit is in Section 9.6, where the requirement to send the WIT and PoP over a 'server-authenticated TLS' connection would also name mTLS. No WG response is in the material.

    • An implementer choosing WIT lifetimes would watch whether the WG tightens the 'on the order of hours' guidance for exp.
    • A deployer sending WITs over mTLS between services would benefit if Section 9.6 states that mTLS satisfies the channel requirement.
  • DiscussionIETF WIMSE

    Kathleen Moriarty's review of workload-creds suggests clearer wording and a few security tweaks; Yaron logged it as issue #418.

    Review of draft-ietf-wimse-workload-creds

    Read the explanation

    The review proposes rewording the abstract to say credentials are bound to the identity rather than represent it. It also proposes stating directly in the introduction that the WIT is for application-layer protocols such as HTTP and the WIC is for transport-layer protocols, mainly mTLS. For Section 5 it suggests explaining that TLS termination at a load balancer is a reason to use an application-layer credential. For Section 5.1 it asks whether the exp guidance of hours should be shorter, and why the draft says deny-list rather than allow-list. For Section 9.6 it suggests allowing mTLS as well as server-authenticated TLS. The message is truncated, so later comments are not visible. Yaron recorded it as s2s-protocol issue #418. These are suggestions, not adopted changes.

    • Implementers choosing between WIT and WIC for a deployment with TLS-terminating load balancers.
    • Operators setting WIT lifetimes and deciding between deny-list and allow-list status mechanisms.
    • Related in OAuth WG: draft-ietf-oauth-status-list. The review questions deny-list versus allow-list token status in the WIT, which is the area Token Status List covers; the material does not link the two drafts.

On the mailing list