Revocation that tells the truth

“Instant revocation” is one of the more common promises made about credential systems, and it is worth being direct about why it is the wrong promise to make, for anyone’s system, not only ours. Revocation is not a button that reaches out and switches a credential off wherever it currently is. It is a fact recorded somewhere, which the next party to check that credential will see, or will not, depending on whether they ask the place the fact was recorded.

That is not a flaw to be engineered away. It is what revocation is, in any system where a credential can be verified without calling back to its issuer, which is exactly the property that makes an offline-verifiable credential useful in the first place.

Why “instant” cannot be true for an offline-verifiable credential

A VAID is deliberately checkable without a network call: a verifier holding the issuer’s public key can confirm a signature is authentic entirely locally, in a browser, with no account and no request to anyone. That is a real and valuable property, and it is also precisely why instant, universal revocation cannot coexist with it. If checking a credential never requires contacting a central service, then revoking that credential cannot reach into every place it might currently be held and switch it off, because nothing in the design ever asked those places to check in.

The honest trade is this: offline verification buys resilience and buys the ability to check a credential with no cooperation from whoever issued it, and the cost of that is that revocation is a fact a verifier has to go and look up, not a signal that propagates to every verifier the instant it is recorded. Any system claiming both properties simultaneously, instant revocation and fully offline verification, is claiming something that is not mechanically possible, not something we have simply not gotten around to building yet.

What is actually true today: refused at the next check

The honest description of revocation, here and in any comparable system, is “refused at the next check.” When a credential is marked revoked somewhere a verifier consults, that verifier refuses it from that point on. What that promise depends on is whether the verifier in question actually consults a revocation record at all, and that is where today’s reference implementation is deliberately candid about a real limitation rather than quiet about it.

The open reference mint’s revocation list lives in memory only. It does not survive a process restart, and a restarted process has no way to detect that it has restarted, so it comes back vouching that nothing is revoked, including a credential that was revoked before the restart. For a bearer credential, where holding the proof is what grants the authority, that is a genuine exposure, not a cosmetic one, and we would rather say so plainly than let a demo’s clean behaviour stand in for the production property.

The fix is not mysterious and the seam for it already exists in the open package: revocation is a pluggable check, deliberately three-state (allowed, revoked, or unknown-because-the-store-could-not-be-reached) and lineage-aware, so revoking a parent credential also revokes everything delegated from it. Critically, it fails closed: if the revocation store cannot be reached, the answer is “cannot verify,” not “assume fine.” A durable backend, one that survives a restart and is reachable from every verifier that needs an answer, slots into that same seam without touching anything else in the system. That durable, always-reachable revocation store is one of the commercial pieces that sits alongside the open standard, precisely because making it durable, fast and highly available at scale is real infrastructure work, not a configuration flag.

Bounded by expiry: the other half of an honest answer

Refusal at the next check only closes the gap for verifiers that actually make a check against a live, durable revocation record. A credential that is never checked against one, because it is verified entirely offline, in a browser, with no revocation list published at all, stays valid for as long as the credential itself says it is valid, revoked or not. This is not a hidden caveat: a VAID verified this way states plainly, on every result, that the verdict establishes authenticity and expiry, and does not and cannot consult revocation, because there is no published revocation list behind that check.

This is why expiry matters as much as revocation, and arguably more, for any credential that might be verified offline. A short-lived credential bounds the worst case even when revocation cannot reach that particular check: the exposure window after something goes wrong is never longer than however long that credential was ever going to be valid for in the first place. A credential that lives for an hour and is compromised has an hour of exposure, full stop, regardless of whether anyone successfully revokes it in that window. A credential that lives for a year and is compromised has, in the worst case, a year, unless every single party that might verify it happens to be checking a revocation list that was updated in time.

The practical implication for anyone evaluating an agent identity system is to ask two separate questions, not one. First: if I revoke this credential right now, which verifiers will actually see that, and how quickly? Second, and the one that matters when the honest answer to the first is “not all of them, and not instantly”: how long is this credential good for if nobody’s revocation check ever catches it? A system that can only answer the first question well, while issuing credentials with long or unbounded lifetimes, has not actually solved revocation. It has moved the exposure from “unrevoked” to “revoked but not everywhere yet,” which is smaller but is not the same thing as safe.

What this means in practice

Treat “instant revocation” as a claim to be sceptical of wherever you encounter it, including from us, and ask instead for the two things that are actually true and actually checkable: where does a revocation record live, which verifiers consult it and how fast, and how long does a credential remain valid if that check never happens for some reason. Those two answers, not a marketing promise, are what determines how exposed you actually are the day something needs to be revoked.