Wiki · Concept · Last reviewed June 25, 2026

Token Status List

Token Status List is an IETF OAuth mechanism for publishing signed status information about many referenced tokens, including credentials that may be revoked, suspended, or otherwise no longer valid.

Category: Concept Updated: June 25, 2026 Tags: digital identity, revocation, verifiable credentials, token status, AI governance

Definition

Token Status List, usually abbreviated TSL, is an IETF OAuth Working Group specification for representing status information about signed tokens. The current datatracker entry is draft-ietf-oauth-status-list-21, titled Token Status List (TSL), with Tobias Looker and Paul Bastian listed as authors. The datatracker shows the document in the RFC Editor Queue and submitted to the IESG for publication as a Proposed Standard.

The draft defines a status mechanism, data structures, and processing rules for tokens secured by JOSE or COSE. Its examples include JWT, SD-JWT, CBOR Web Token, and ISO mdoc. In plain terms, TSL lets a relying party ask whether a referenced token is still valid, invalid, suspended, or assigned another registered status value.

TSL is not a wallet, verifiable-credential data model, or presentation protocol. It answers a narrower question: after a token has been issued and presented, where does a verifier get fresh, signed information about that token's current status?

How It Works

The draft calls the checked object a referenced token. A referenced token can contain a status claim that points to a status mechanism. For TSL, that mechanism is status_list, and the referenced token points to a status list token plus an index inside that list.

A status list is a compressed byte array. The issuer chooses whether each entry uses 1, 2, 4, or 8 bits, and each referenced token receives a distinct index. Packing entries into one list is the key design move: one signed list can describe many thousands or millions of tokens instead of publishing one status object per token.

A status list token wraps the list in a signed JWT or CWT, protecting integrity while allowing separate hosting or offline use. The draft defines HTTP behavior, media types for JWT and CWT status-list tokens, and registered status values including valid, invalid, suspended, and application-specific ranges.

Credential Stack

TSL fits beside, rather than inside, credential formats. The SD-JWT VC draft says that when an SD-JWT VC has a status claim using the status_list mechanism, the associated status list token has to be a JWT. The W3C Verifiable Credentials Data Model v2.0 uses a different vocabulary, credentialStatus, for discovering status information such as whether a credential is suspended or revoked. Those are related status ideas, but they are not the same specification.

This distinction matters for governance. A wallet may present a credential through OpenID for Verifiable Presentations; the credential may be SD-JWT VC; status may be checked through Token Status List. The issuer, status issuer, status provider, verifier, and wallet may be different organizations. A source-disciplined system names those layers.

Agent Context

For AI agents, Token Status List is part of the difference between a credential that merely looks valid and one whose current authority has been checked. A procurement agent, hiring workflow, school-service bot, benefits assistant, browser agent, or access-control tool may receive a signed credential that was valid at issuance but revoked later. If the agent skips status, it can turn stale authority into a live decision.

Agent systems should treat status checks as evidence, not as permission. A valid status does not answer whether the verifier was allowed to ask, whether the requested action is proportionate, or whether a human approved delegation. It only says that the referenced token's status mechanism currently supports use under the relevant policy.

Governance Risks

The first risk is stale status. Caching makes TSL scalable, but a relying party that caches too long can miss revocation, suspension, or policy changes. The second risk is correlation. The draft notes that the URI-and-index tuple inside a referenced token is unique and traceable; colluding parties can compare status claims and link repeated presentations.

The third risk is status leakage. Status values beyond routine valid or invalid states can reveal more than the verifier needs to know. A suspended credential may encode a labor, school, legal, financial, or safety dispute. The fourth risk is status-provider power. A status provider can become a critical intermediary even when it is not the original issuer.

Governance Pattern

Source Discipline

Claims about Token Status List should name the draft version, token format, status mechanism, status issuer, status provider, status-list token format, cache policy, and relying-party behavior. Do not collapse TSL into OAuth Token Revocation, OAuth Token Introspection, W3C credential status, SD-JWT VC, or a legal conclusion that a person has current authority.

Spiralist Reading

Spiralism reads Token Status List as the record of withdrawal. A credential is never just a badge; it is a relationship over time. The status layer says that authority can decay, pause, be contested, or be revoked. Machine-mediated institutions need that humility, but they also need appeal. A fast revocation check without a humane correction path is only a sharper gate.

Open Questions

Sources

Return to Wiki