Revocation Status Check¶
Validity monitor — instantiates Evidence-Bound Authentication
Checks whether an otherwise-valid credential has been revoked, expired, or pushed out of scope since it was issued — so trust is withdrawn the moment its basis changes.
Every other check in the archetype asks whether evidence was good when it was issued or presented. Revocation Status Check asks the one remaining question: is it still good, right now? A credential can be perfectly formed, correctly bound, and unexpired on its face, yet have been revoked minutes ago — its private key stolen, its holder fired, the certificate behind it withdrawn for fraud. This is the freshness gate that catches state which changed after issuance, and its defining discipline is that it fails closed: a status of revoked, expired, or unknown withholds trust rather than granting it. A check that treats "I couldn't find out" as "fine" is not a revocation check at all.
Example¶
A browser opens a connection to a website and validates its certificate chain — signatures intact, not expired, issued by a trusted authority. All of that can be true while the site's private key was compromised last week and its certificate revoked in response. So the client consults revocation status: it queries an OCSP responder or a certificate revocation list (increasingly, the answer is stapled to the handshake or pushed to the client in advance), and on a "revoked" result it refuses the connection despite the otherwise-valid chain. The revealing case is the failure path. If the responder is unreachable and the client soft-fails — treating "couldn't check" as "not revoked" so the page still loads — the entire control silently evaporates exactly when an attacker who has blocked the responder needs it to.[n1]
How it works¶
What distinguishes it is that it consults an authoritative, time-sensitive source at the moment of use and couples the answer to a hard decision:
- Query current status — check the credential against a live or recently-published source of revocations, expiries, and scope narrowings, rather than trusting the credential's own self-description.
- Resolve the freshness-versus-availability tension — decide how current the status must be, trading a live lookup's latency and fragility against a cached list's staleness or a short-lived credential's fast expiry.
- Fail closed and withdraw — map revoked / expired / unknown to an immediate denial for the pending action, so a change in the credential's basis translates into an actual loss of trust.
Tuning parameters¶
- Freshness window / cache lifetime — how stale an answer may be. Fresher status catches a revocation sooner; longer caching cuts latency and survives outages but widens the window of wrongful trust.
- Fail-open vs. fail-closed — what to do when status is unreachable. Fail-closed preserves the security guarantee but is brittle to outages; fail-open preserves availability and can nullify the control. This is the central dial.
- Distribution model — pull (a live query per use), push (a pre-distributed revocation set), or short-lived credentials that expire fast enough to sidestep revocation altogether.
- Scope of the check — revocation only, or also expiry, attribute or scope narrowing, and privilege step-down since issuance.
- Re-check cadence — at authentication only, or continuously through a long-lived session, so a mid-session revocation is actually honored.
When it helps, and when it misleads¶
Its strength is closing the "valid but compromised or withdrawn" gap that signature and binding checks structurally cannot see: it turns a point-in-time credential into a continuously-conditioned one and enables fast, decisive trust withdrawal.
Its signature failure is the soft-fail: to preserve availability, a system treats an unreachable status service as an implicit "not revoked," which quietly disables the control precisely when it is under attack — and a stale revocation list or a "check once, then trust the session forever" model has the same shape. The classic misuse is choosing fail-open by default for uptime and never revisiting it, so the whole mechanism is decorative. The discipline is to fail closed — or adopt stapling and short-lived credentials so a fresh answer is always present — to bound acceptable staleness explicitly, and to re-check long sessions rather than trusting an entry credential indefinitely.
How it implements the components¶
Revocation Status Check fills the freshness-and-withdrawal subset of the archetype — the components that keep a past verdict from outliving its basis:
freshness_revocation_and_scope_check— its core: is this credential still current, un-revoked, unexpired, and used within the scope it was granted?verdict_to_trust_coupling_rule— the fail-closed rule that maps a revoked, expired, or unknown status to immediate withdrawal of trust for the pending action.
It does not establish who the subject is or size the factor set (that is Multi-Factor Authentication), validate the issuing certificate chain (Certificate Chain Validation), or own the full verdict taxonomy across all evidence (the Credential Verification Workflow) — it contributes only the time-sensitive status and its fail-closed coupling.
Related¶
- Instantiates: Evidence-Bound Authentication — it supplies the freshness gate that lets an accepted binding be un-accepted the moment its basis changes.
- Consumes: Certificate Chain Validation — it checks the current status of a credential whose structural validity another mechanism has already established.
- Sibling mechanisms: Certificate Chain Validation · Digital Signature Verification · Multi-Factor Authentication · Liveness or Presence Check · Provenance Chain Review · Zero-Knowledge Authentication Protocol · Federated Identity Assertion · Credential Verification Workflow · Challenge-Response Authentication
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Revocation Status Check operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it checks whether an otherwise-valid credential has been revoked, expired, or pushed out of scope since it was issued — so trust is withdrawn the moment its basis changes.
Independent corroboration: The frozen evidence defines Revocation Status Check as 'Checks whether an otherwise-valid credential has been revoked, expired, or pushed out of scope since it was issued — so trust is withdrawn the moment its basis changes', so its operative form is Control, Automation & Runtime.
Nearest alternative: Monitoring, Sensing & Alerting — Revocation Status Check includes features of ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Checking whether a still-parseable digital credential has been revoked is a canonical public-key infrastructure and access-control operation. Security practice supplies threat context, while law contributes the more general doctrine that previously granted authority can be withdrawn.
Related originating lineages:
- Law & Governance — law_governance contributes rights, duties, authorization, tenure limits, and accountable procedure to the mechanism’s formative or independently convergent form; that contribution does not displace the primary computer_science lineage.
- Security Studies & Intelligence Analysis — security_intelligence contributes adversarial analysis, credential trust, containment, and competing-hypothesis assessment to the mechanism’s formative or independently convergent form; that contribution does not displace the primary computer_science lineage.
Review resolution: The blind reviewers disagreed on primary lineage (computer_science versus security_intelligence); authoritative or primary research supports computer_science as the best historical origin. Checking whether a still-parseable digital credential has been revoked is a canonical public-key infrastructure and access-control operation. Security practice supplies threat context, while law contributes the more general doctrine that previously granted authority can be withdrawn. The cited NIST CSRC Glossary: Online Certificate Status Protocol directly supports the defining operation used in that choice. All independently supported contributing domains are retained without an arbitrary cap, while domain_reach=specialized records later applicability separately from provenance.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The check is only as timely as its own source and its session model. Revocation verified at login says nothing about a session that then stays open for days; unless the credential is short-lived or re-checked, a holder revoked at noon may keep an authenticated session running until evening. Deciding when trust is re-evaluated is as consequential as the lookup itself.
[n1] Soft-fail (fail-open) revocation checking — treating an unreachable or non-responsive status source as "not revoked" so the connection proceeds. It is a well-documented weakness of online revocation checking, because an attacker who can block the status query also suppresses the very signal that would deny them. ↩