Every Revocation Design Has a Window. Ask How Long Theirs Is

The question a signature cannot answer

A verifier checks a credential's signature and it is valid. That proves the credential was issued by the party it names and has not been altered since.

It says nothing about whether the credential is still good. An employee leaves, a licence is suspended, a passport is cancelled, an account is closed. The signature over the old statement stays mathematically perfect forever.

So every credential system needs a second question, asked at verification time: has this been withdrawn since it was issued. How a system answers that is not a detail. It decides whether the system works offline, what the issuer learns about the holder, and how long a withdrawn credential keeps working.

The three answers, and the cost of each

Publish a list, let verifiers pull it. The verifier downloads a compact structure covering many credentials and checks a position in it. The issuer learns nothing about individual checks, and the verifier can work from a cached copy. The cost is staleness: the list is only as current as the last refresh, and the window between a revocation and a verifier noticing is exactly the refresh interval.

Ask the issuer directly, per credential. Fresh to the second. The cost is that the issuer now receives a signal every time the credential is presented, which means the party who issued your identity learns where and when you use it. This is the oldest known problem in certificate infrastructure and it did not stop being a problem when credentials got a new name.

Make credentials expire quickly. No lookup at all. Validity is bounded by construction, and withdrawing someone means declining to reissue. The cost moves to reissuance volume and to a floor under how fast a withdrawal can take effect.

There is no fourth option that avoids all three costs, and industry-wide there is no settled answer. A vendor presenting revocation as solved has picked one of these and not told you which.

The privacy cost is the one buyers skip

A live per-credential status check turns every verifier into a reporter. The issuer learns that credential 8,412 was presented at 09:14 today, and repeated over months that is an activity log about a person, assembled by an institution the person never chose to keep one.

Status lists reduce this rather than eliminating it. Fetching a slice of a list still tells the issuer roughly which cohort of credentials somebody is asking about. Smaller signal, same shape.

For a buyer this is not an abstract concern. If your regulator or your customers care about who can profile a user's movements, the revocation mechanism is one of the places that profiling gets built, quietly, as a side effect of a correctness check.

What that design buys, and what we cannot show you

It removes an availability dependency. There is no status service to be unreachable at verification time, no question of whether a verifier fails open or fails closed when a lookup times out, and no per-check signal reaching the issuer.

For a verifier operating in poor connectivity, or for anyone who does not want an issuer to receive a stream of presentation events, a design with no lookup in the path is a genuine property rather than a compromise. It is the same trade certificate infrastructure has been making for thirty years, chosen deliberately here rather than inherited.

Neither mechanism is reproducible from a cold terminal. Confirming the epoch-lapse behaviour or the status check both require holding a real issued credential and driving our verification flow, which is not something a stranger can do today. We would rather name that gap than describe a command that does not exist.

What to ask any credential vendor

"What is the longest a revoked credential can still verify?" Every design has a number. A vendor who answers "immediately" is describing a live per-check call to the issuer and has a privacy cost they have not mentioned yet.

"Who learns that I checked?" The answer separates a downloaded list from a phone-home, and it is invisible in a demo because both look identical to the user.

"What happens when the status service is unavailable?" Fail open accepts revoked credentials during an outage. Fail closed rejects good ones. Both are defensible and a system that has not chosen deliberately will discover its choice during an incident.

"Can a verifier work offline, and for how long?" This is the same question as the first one asked from the other end, and comparing the two answers is a fast way to find out whether a vendor has thought about it.

Where this leaves a decision

If you need withdrawal to take effect the instant it is decided, our BBS+ path does not do that and you should ask us for the epoch length before assuming a number.