Skip to main content

Status List

A status list is a compact, signed list an issuer publishes so that anyone holding one of its credentials can be checked for revocation without the issuer being asked about that credential specifically.

The list is a bitstring: every credential the issuer hands out is assigned an index in it, and the bit at that index says whether the credential is still valid, revoked or suspended. Token Status List reserves one or two bits per entry depending on how many states the issuer needs to distinguish, since suspended is a separate, reversible state from a permanent revocation. The credential carries the URL of the list and its own index, so a verifier fetches the list once, caches it for a period the issuer sets, and reads a single bit for every check afterwards rather than calling the issuer each time. Because the whole list is downloaded at once and covers every credential the issuer has ever handed out, the issuer never learns which credential was looked at or by whom, since the herd hides the individual: this is the privacy property that makes status lists preferable to per-credential revocation checks, which would let an issuer track exactly when and how often a given credential is used. Compressed, a list covering hundreds of thousands of credentials is a few kilobytes, and lists are typically re-published on a fixed schedule or a content delivery network so a verifier's cached copy stays current without a round trip to the issuer for most checks. The two specifications in use are Token Status List for JWT and CWT credentials, which the EUDI ARF adopts for SD-JWT VC and mdoc attestations, and Bitstring Status List for the W3C verifiable credentials data model. An issuer that instead wants to avoid revocation checks altogether can issue short-lived credentials that simply expire, but status lists remain the mechanism of choice wherever a credential needs a longer validity period.

Can a verifier tell which credential someone is checking by watching status list requests?

No, that is the point of downloading the whole list. Because a verifier fetches the entire bitstring covering every credential the issuer has ever issued, rather than asking about one specific credential, the issuer cannot tell which entry the verifier cares about. The individual check is hidden inside a large batch of unrelated entries, which is what keeps status checking from turning into a way to track credential use.

Back to the glossary