Credential Revocation: How Status Lists Keep Verifiable Credentials Trustworthy

A signed credential proves what was true at the moment of issuance. The problem is that the world moves on. A phone gets lost. A KYC check expires. An identity provider discovers a fraud pattern after the fact. A credential that was honestly issued in March can be something you very much do not want a verifier to accept in September. So every serious credential system needs an answer to one question: how does a verifier learn that a credential it can otherwise validate has been pulled?

That answer is revocation, and the most practical mechanism for it today is the status list.

Why a valid signature is not enough

When a verifier checks a verifiable credential, the signature tells it two things: the credential was issued by a party it trusts, and the contents have not been altered since. Both can be true while the credential is, in fact, dead.

Consider the failure cases:

• Lost or stolen device. The credential is genuine, the signature is genuine, but it is no longer in the hands of the person it describes.
• Expired KYC. Many regulated checks have to be refreshed on a schedule. The credential was valid when issued and is now stale.
• Fraud discovered later. The identity provider issues in good faith, then learns the underlying document was forged. Every credential derived from that check has to be invalidated.

An expiry date inside the credential handles the predictable case but not the urgent one. You cannot wait for a year-long credential to lapse on its own when a device went missing this morning. Revocation has to be something the issuer can trigger at any time, and something the verifier can observe quickly.

The naive approaches and why they fail

The obvious design is to have the verifier ask the issuer directly: "is credential number 12345 still good?" This works, and it is also a privacy disaster. Every time you present your credential, the verifier contacts the issuer with your specific credential identifier. The issuer then sees a live feed of where you go and when. You would have rebuilt exactly the surveillance problem that user-held credentials were supposed to remove.

The other naive design is a published list of every revoked credential's identifier. This protects nobody either, because the list itself reveals which specific credentials are dead, and checking it can still leak which credential you hold. It also grows without bound.

A good revocation mechanism has to satisfy three constraints at once: the issuer can revoke in near real time, the verifier can check without contacting the issuer about you, and the check reveals nothing about which individual is being verified. The status list is the design that hits all three.

How a status list works

A status list is, at its core, a long array of bits. Position zero is the first credential, position one the second, and so on. Each bit means "valid" or "revoked." When the issuer creates a credential, it assigns that credential an index into the list. Inside the credential, in a field the verifier can read, it records two things: the URL of the status list and the index to check.

To revoke a credential, the issuer flips the bit at that index from zero to one and republishes the list. Nothing else changes. The credential in your wallet is untouched. What changed is one bit in a public document.

When a verifier validates your presentation, it does the following:

1. Reads the status list URL and your index from the credential.
2. Fetches the status list. The list is itself a signed credential, so the verifier can confirm it really came from the issuer and was not tampered with.
3. Looks at the bit at your index. Zero means valid, one means revoked.

If the bit is set, the verifier rejects the credential no matter how good the signature is.

Why the bitstring is compressed

A list with one bit per credential is already small. A million credentials is a million bits, which is 125 kilobytes before any compression. But revocation lists are mostly zeros, because most credentials are not revoked at any given moment. Long runs of identical bits compress extremely well. After standard compression, a status list covering hundreds of thousands of credentials routinely shrinks to a few kilobytes.

That size is the point. A verifier can fetch and cache the whole list cheaply, check any index locally, and never reveal which index it cares about. The compression is what makes "download the entire list" a reasonable strategy instead of "ask about one credential."

The privacy property, stated precisely

Here is the part that makes status lists clever. The verifier downloads the same list whether it is checking your credential or anyone else's. The issuer serves a static file and sees a request for a document, not a request about a person. Because the verifier already holds the full list, the issuer cannot tell which index the verifier actually looked at.

So the verifier learns exactly one fact, valid or revoked, and the issuer learns nothing about who is being checked or when. The verifier does not phone home about the specific person. That asymmetry, full answer to the verifier, no tracking signal to the issuer, is the whole reason this mechanism beats a direct lookup.

A practical detail: issuers often pad lists with spare entries and assign indexes in a way that avoids leaking issuance order or volume. The goal is that an outside observer cannot read business intelligence out of the list either.

Real-time revocation and its limits

Revocation is as fast as republishing the list, which can be seconds. The honest caveat is caching. Verifiers cache the list to stay fast and private, so a freshly revoked credential might still be accepted by a verifier holding a slightly stale copy. Issuers manage this by setting sensible refresh windows on the list, and high-stakes verifiers fetch more often. It is a tradeoff between freshness on one side and load and privacy on the other, and different use cases land in different places.

This same revocation capability is what makes delegated authority safe to hand out. When a principal issues a scoped credential to an AI agent, as we describe in know your agent, the status list is the kill switch. Flip one bit and the agent's authority dies everywhere at once, with no need to chase down every service the agent ever touched.

Where OpenKYC fits

OpenKYC is building a reusable KYC marketplace on open standards (W3C Verifiable Credentials, OpenID4VC): verify once, hold the credential in your own wallet, reuse it everywhere, and earn every time it is used. A reusable credential is only trustworthy if it can be pulled the moment it should not be honored, so status-list revocation is not an optional extra for us, it is what lets verifiers rely on a credential they did not issue themselves. Join the waitlist at openkyc.org.