The Status Endpoint Is Live and a Stranger Still Cannot Use It

The gap described below is small and specific, and it is ours.

The mechanism, and why this shape won

A verifier needs to know whether a credential has been withdrawn. Asking the issuer per credential is fresh and leaks: the issuer learns when and where the credential is used.

So the answer is to publish a compact structure covering many credentials at once. Each credential carries a pointer to a position in it. A verifier fetches the structure, checks a position, and learns one bit.

The privacy gain is that the issuer sees a request for the whole list rather than a question about one person. Not perfect, since fetching a particular list still narrows a cohort, and materially better than a per-credential lookup.

The design detail buyers should notice

The list has to be big enough to hide in.

A status structure covering ten credentials tells an issuer almost exactly who is asking. One covering a hundred thousand tells them very little. The privacy property scales with the population sharing the list, which means it is weakest exactly when a system is new and has few credentials.

That is an uncomfortable property for any early deployment, ours included, and it is rarely mentioned because it is a fact about adoption rather than about design.

The correction that belongs on this page

Our own record of this was wrong once, and the way it was wrong is worth repeating because the mistake is easy.

An earlier probe requested the route without the identifier segment, got a routing miss, and concluded that no endpoint existed. Two different things return the same status code here: a request for a list that does not exist, and a request to a path that does not exist. Only the response body distinguishes them.

Reading the body rather than the code is what corrected it. That is the general lesson: when a probe returns a failure, check whether you probed the thing you meant to.

What to ask any credential vendor about revocation

"Can I fetch a status structure right now, without an account?" If yes, the mechanism is real. If the route exists but you cannot address it, that is our situation and it is worth naming as distinct from "not built".

"How many credentials share a list?" This is the privacy property, and it is a number they either know or have not thought about.

"What does your verifier do when the status service is unreachable?" Fail open accepts withdrawn credentials; fail closed rejects good ones. Both are defensible and the choice should be deliberate.

"How stale can a cached status be?" There is a cache header, and therefore a window, and therefore an interval during which a withdrawn credential still verifies.

Where this leaves a decision

If you need to verify our revocation mechanism yourself before relying on it, you cannot today, and the missing piece is a published index rather than a missing implementation.

If you are weighing the mechanism as a design, it is the right shape for the credential format we issue, the privacy property it provides is real but scales with a population we do not yet have, and both limits are stated here rather than left for you to work out.