Skip to content

Revocation Status Check at Use

Revocation-check protocol — instantiates Use-Time Precondition Binding

At the point of use, queries a live revocation source to confirm a previously-granted authority has not since been withdrawn before acting on it.

Revocation Status Check at Use assumes the grant was valid when it was issued and asks a different question at the moment of use: has it been withdrawn since? Rather than bounding the grant's lifetime (a lease) or excluding other actors (a lock), it keeps a live channel to a revocation source — a blocklist, a hot-list, a certificate revocation list, a consent-withdrawal registry — and consults it at the use site, refusing to act if the authority now reads as revoked. Its defining move is to treat revocation as a signal that flows the other way: the grant is presumed live, and the check exists to catch the specific event of it being actively killed in the gap between issue and use.

Example

A cardholder reports their card stolen at 2:00 pm; the issuer flags the number on its authorization hot-list. At 2:05 pm someone tries to buy electronics with it. The terminal does not rely on the card merely being well-formed and un-expired — checks that passed cleanly when the card was issued. It sends an authorization request that, at that instant, is matched against the hot-list and declined. The window that matters is the five minutes between the report and the swipe, and the use-time query is what makes that fresh revocation bind the transaction. The card's issue-time validity was never in question; what changed — and what only a check at use could catch — is that the authority behind it had since been pulled.

How it works

  • Presume valid, check for the kill signal. The grant is not re-derived from scratch; only its revocation status is queried.
  • Query at the use site, freshly. The check is bound to the moment of action, not inherited from an earlier gate — a cached "not revoked" quietly reintroduces the very gap it was meant to close.
  • Consume an authoritative signal. It reads from whoever owns revocation — the issuer, the CRL, the consent registry — not from a local guess or a copy that may lag.
  • Decide fail-open or fail-closed. When the source is unreachable, the rule must state whether to proceed or deny; that single choice is the mechanism's sharpest edge.

Tuning parameters

  • Check freshness — a live query every use versus a short-cached status; caching cuts latency and load but reopens exactly the gap the check exists to close.
  • Fail-open versus fail-closed — what to do when the revocation source is down; fail-open preserves availability at the cost of honoring possibly-dead grants, fail-closed does the reverse.
  • Revocation latency — how fast a withdrawal propagates from the owner to the point of use; the real protection is never fresher than this lag.
  • Scope of the query — check only this credential versus the whole trust chain behind it; broader checks catch upstream revocations but cost more per use.
  • Escalation on a hit — what a "revoked" result triggers — silent deny, alert, lock-out, human review — matched to the stakes of acting on a dead grant.

When it helps, and when it misleads

Its strength is that it is the only mechanism in this family that catches a grant actively killed mid-gap. Expiry cannot — a lease is still comfortably inside its window — and a lock does not, because the resource never changed, the authority did. It is indispensable wherever authority can be pulled: stolen credentials, revoked certificates, withdrawn consent, terminated access.

Its failure mode is that it is only as fresh as the revocation source and only as timely as propagation — a check that hits a stale blocklist gives confident false assurance. Its notorious weakness is soft-fail: when the revocation server is unreachable, systems quietly fall open and honor everything, a criticism levelled for years at online certificate revocation.[1] The classic misuse is caching the "valid" result for performance until the check is revalidating almost nothing. The discipline is to keep the check on the live path, to decide fail-open versus fail-closed by the stakes rather than by convenience, and to treat propagation latency as a first-class metric.

How it implements the components

  • invalidation_and_revocation_signal — the mechanism exists to consume this signal; the withdrawal event is its entire input.
  • use_time_revalidation_rule — the rule that a fresh revocation query must run at the use site, never inherited from an earlier check.
  • stale_authority_escape_path — the defined path when a grant comes back revoked (deny, alert, lock out, escalate) and when the source itself is unreachable.

It does not set a validity_window_or_lease (that's Lease-Bound Capability Token) or keep a check_use_audit_trace of which version it decided against (that's Snapshot-Pinned Decision); it watches for one event — the grant being killed — and reacts, rather than bounding time or versioning evidence.

Notes

A revocation check protects only against withdrawal — not against every way a precondition can go stale, such as a balance dropping or a data value shifting. It is commonly paired with a lease: the lease bounds the worst case (a grant can live no longer than its window) while the revocation check catches early kills inside that window. Neither alone covers both the "grant expired" and "grant pulled" failure modes.

References

[1] The Online Certificate Status Protocol (OCSP) checks a certificate's revocation status at connection time. Its widely-noted weakness is soft-fail — clients that treat an unreachable responder as "not revoked" and proceed, honoring a possibly-revoked certificate for the sake of availability. It is the canonical illustration of why the fail-open / fail-closed choice is the heart of any use-time revocation check. ↩