Revocation

Revocation is how an issuer takes back a credential's validity before it naturally expires, a passport gets cancelled, a certificate gets pulled, a professional license gets suspended. Without a working revocation mechanism, a "verifiable" credential only ever proves what was true at issuance, never what's true now.

This is not a new problem invented by digital identity. Certificate authorities have solved (imperfectly) the same problem for TLS certificates since the 1990s: X.509 Certificate Revocation Lists (CRLs, standardized in RFC 5280) publish a periodically-updated blacklist; the Online Certificate Status Protocol (OCSP, RFC 6960) lets a client ask a responder about one certificate directly, at the cost of leaking that query to the responder. Verifiable Credentials inherit the same tradeoff and largely the same fix: a status list (see the Status List entry) that lets a verifier check revocation without a live per-credential call to the issuer.

Two failure modes revocation has to survive

1. The issuer forgets to check, or the verifier's cached view is stale: a credential can look valid to an offline or slow-to-sync verifier well after the issuer revoked it.
2. A live revocation check itself leaks information, the CRL/OCSP privacy problem, carried forward. Status lists reduce but don't eliminate this: fetching a slice of a bitstring still tells the issuer roughly which slice, roughly which cohort of credentials, is being checked.

There is no universally "solved" answer here. Every design trades off latency, privacy, and staleness differently, industry-wide: this is not a Solidus-specific gap.

Solidus status

Solidus's BBS+ implementation is UNAUDITED, audit targeted H2 2026 via NLnet NGI Zero, none exists today, and everything below runs on public testnet; there is no mainnet. With that stated: Solidus runs two different revocation mechanisms depending on credential type, both composed from existing cryptographic building blocks rather than a new invented primitive.

• For SD-JWT VC credentials, Solidus uses status-list-style revocation checking (see Status List).
• For BBS+ credentials specifically, there is, by design, no per-credential revocation lookup in the verify path at all. Instead, credentials carry a bounded lifetime tied to a rotating "epoch key": the issuer only publishes signing keys for the current and previous (grace-period) epoch, so a credential signed under a lapsed epoch simply stops verifying once that epoch's key is no longer published. A holder who needs to be cut off immediately is excluded from the next reissuance batch, and their last valid credential expires at the end of its epoch's grace period, bounded latency, not instant revocation.

There is no independently-reproducible public proof for either mechanism today: confirming the BBS+ epoch-lapse behavior or the SD-JWT status check both require holding a real issued credential and driving Solidus's own verify flow, not something a stranger can check from a cold terminal. This entry names that gap rather than inventing a command that doesn't exist.