How Revocation Works, and the One Case Where the Authoritative Answer Is the Stale One

What one revoke call does

Marks the credential revoked in the database, idempotently, and safely if two requests race.

Invalidates the cached status document immediately, so the next fetch reflects the change.

Fires a webhook to the operator's configured endpoint.

And then asks the chain to revoke the anchored record, if the credential was anchored at all.

The cache lifetime is not the propagation delay

The signed status document is cached for sixty seconds, and ten for the time-critical list. That number is a cache lifetime, not a delay before a revocation becomes visible.

Revoking busts the cache in the same call, so the document a verifier fetches after that moment already carries the change.

The real delay is how often the verifier refetches, which is the verifier's choice and not ours. That is a meaningfully better design than the sixty-second number suggests, and it is worth stating before the problems.

And now the inversion

The database revoke happens first, then the chain revoke. That order is deliberate and correct: a failure leaves the credential revoked in the safe direction rather than accepted.

But the two paths a verifier can use disagree during that failure. The code says so in its own comment: the cached path already fails closed, and the live path still says active until the chain revoke is retried.

So the authoritative path is the one that can be stale. The page for verifiers recommends the live path for anything consequential, which is right about bypass-resistance and needs this qualifier: during a chain-revoke failure, live is the path that still says yes.

The correct reading for a verifier: treat a revoked verdict from either path as revoked. Neither path lies in the dangerous direction on its own, but only together do they cover both failure modes.

And nothing retries it

The comment says the divergence is logged for retry. Measured: there is no retry.

Four job queues exist: the registry anchor, the validation emission, the attestation emission and webhook delivery. A chain revoke is not one of them.

CONTROL, and it is what makes this a decision rather than a missing framework: the attestation revoke IS queued. Somebody wired retryable revocation work for one of the two emissions and not for the chain.

So the divergence persists until a person notices a log line.

The status list has no rollover

Each tenant gets one list per purpose, holding sixty-five thousand five hundred and thirty-six positions.

Positions are handed out by a counter that only moves forward. Revoking a credential does not free its position, so the number is a lifetime issuance budget rather than a live-credential capacity.

When it fills, issuance stops with an error saying a rollover is required. Measured: the word naming that operation appears exactly once in the entire backend, inside that error message.

Nothing creates a second list. The lookup takes the most recent existing one and creates a list only when none exists at all.

An error message that names an operation nobody implemented is a trap left for a future operator, and the cheapest moment to close it is before somebody hits it at scale.

What the revocation path gets right, at the same volume

Idempotent and race-safe. A repeat call returns cleanly, and two simultaneous calls converge on the same outcome rather than double-writing.

The safe order. Database first, chain second, so a partial failure leaves the credential revoked rather than accepted.

Honest comments. The divergence is named in the code rather than discovered by a reader, which is how this page found it.

And the cached check fails closed, so a verifier that supplies a status reference and cannot validate the list gets a refusal rather than a shrug.