Status List

A status list answers one question cheaply and privately: is this specific credential still valid, or has it been revoked, without the verifier calling the issuer every time, and without the issuer learning who's asking.

The naive way to check revocation is a per-credential lookup: the verifier asks the issuer "is credential #4471 still good?" The issuer learns exactly which credential was just checked, when, and by inference against whom: a real privacy leak, since the verifier just told the issuer where its own credential is being used. A status list flips this: the issuer publishes one compact bitstring (or a signed token wrapping one) covering thousands or millions of credentials at once. Each credential gets an index into that list; the verifier fetches the whole list (or a signed slice of it) and checks one bit. The issuer never learns which credential, or which verifier, made the check.

The two specs that matter

• Bitstring Status List (a W3C Verifiable Credentials Working Group specification: the current name for what was originally called StatusList2021, with the approach driven substantially by Digital Bazaar and the wider VC community), designed for JSON-LD/Data-Integrity -secured Verifiable Credentials.
• Token Status List (an IETF OAuth-working-group draft), the equivalent mechanism for JWT- and CWT-based credentials, like SD-JWT VC and mdoc, since those don't carry a JSON-LD @context to hang a Bitstring List off of.

Both do the same job over a different wire format, matched to how the credential itself is secured.

Solidus status

Solidus's live credential format is SD-JWT VC, confirmed via its shipped OID4VCI issuer, which advertises "format":"vc+sd-jwt", so the relevant mechanism is the Token/JWT Status List family, not the JSON-LD Bitstring List. Internally this shows up as issuance "status slots". Solidus did not design either spec; it depends on existing tooling for the status-list mechanics.

⚠ Corrected 2026-07-31. This entry previously said there was no public, independently-browsable status-list URL. There is one: the capture API registers statusListRoutes at prefix /status-lists, and the handler is GET /:id, which signs a status-list JWT and returns it as application/statuslist+jwt with a 300-second cache header. The 2026-07-17 check tried /status-lists bare, the right prefix, missing the :id segment, so Fastify answered with a route miss, which was read as "no endpoint". Read the response BODY and the two cases separate cleanly: GET /status-lists/1 returns {"message":"status list not found"} (the handler ran) while GET /status-lists returns {"message":"Route GET:/status-lists not found"} (no such route), with GET /v1/health returning 200 as a control. The real remaining limitation is narrower than the one this entry used to claim: no published list id is discoverable, so a stranger cannot fetch an actual list even though the endpoint is live. endpoint is confirmed later, update this entry with the exact URL and command.