How does revocation with a Token Status List work, and why does it preserve privacy?
The issuer publishes a signed, compressed bit array; each credential carries the list's address and its own index, and a verifier fetches the whole list and reads that one bit (0 = valid, 1 = revoked).
* Revocation by bit array: downloading the whole list hides which credential is checked. *
- At issuance, each credential gets a status reference: the URI of a status list and an index in it.
- The issuer publishes the Status List Token, a signed, compressed list of bits. Revoking a credential means flipping its bit and republishing the list.
- A verifier downloads the list from the URI, checks the issuer's signature on it, and reads the bit at the credential's index.
Why it is privacy-friendly: the verifier downloads the whole list, which covers many credentials, rather than asking the issuer "is credential 4711 still valid?". The issuer therefore can't tell which credential is being checked, or by whom, a property called herd privacy. This is how revocation keeps the issuer out of the usage process (the decoupling of issuance and use).
One caveat: the index is a unique value in the credential. If it is the same in every presentation, it can link presentations just like a signature, which is another reason for batch issuance.
Go deeper:
IETF draft: Token Status List โ the bit-array format, its compression and the herd-privacy discussion.