No explainer written for this spec yet. The summary, relations and documented support below are maintained.
A compressed bit list that issuers publish so verifiers can check whether a token or credential has been revoked or suspended.
Token Status List
A compressed bit list that issuers publish so verifiers can check whether a token or credential has been revoked or suspended.
- Where it stands
- Approved, with the RFC Editor
- Documented support
- 0
- Activity
- 2 signals in 90 days
How it relates to other specs
Relations diagram
flowchart LR s_status_list["Token Status List"] s_jwt["JSON Web Token"] s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"] style s_status_list stroke-width:3px s_status_list -->|Builds on| s_jwt s_sd_jwt_vc -->|Builds on| s_status_list
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.
No sourced support entries collected yet. This says nothing about how widely it is used.
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
Mikhail asks the evidence-binding authors to reword claims that a serving party cannot refuse a call over a suspended prior actor.
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
Read the explanation
Kieran has accepted that RFC 8693 Section 4.1 keeps prior actors in nested act claims out of access-control decisions, and the authors will take that reading in -02. Mikhail notes the SCITT -02 text still says a Serving Party cannot refuse a call because a prior actor was suspended. He points out that separately verified delegation tokens give another basis: a chain in the draft-asor-wimse-agent-delegation-chain-03 format is verified hop by hop, and step 7 denies when an accepted status answer marks any token revoked, within the status list freshness window. He suggests wording limited to refusal on the basis of nested act claims, and rewording the phrase that history is neither complete nor evidence.
flowchart LR A[Token with nested act claims] --> B[Serving party reads top-level claims and current actor only] C[Delegation chain tokens] --> D[Verify each hop] D --> E[Check status list answer] E -->|any token revoked| F[Deny]
- Designing an audit or serving-party policy for multi-hop agent calls where an upstream actor is later suspended.
- Choosing whether per-hop authority is checked from act claims (attribution only) or from separately verified delegation tokens with status references.
- Related in OAuth WG:
draft-ietf-oauth-status-list. The delegation-chain draft's status references and freshness window are checked against a status list answer.
- 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.