Turning the page.
Bringing the next chapter into view…
Psst… make reading your own.
Fonts + themes live in Appearance. Your eyes get a vote.
Bringing the next chapter into view…
Information used to determine whether a digital credential has been suspended, revoked, or otherwise updated, independently of whether its signature verifies.
Checking this browser’s read-aloud support…
A signed credential can remain cryptographically intact after the issuer withdraws it. The Verifiable Credentials Data Model separates verification of the secured document from validation against the verifier's rules. Validity dates and credential status are inputs to that later decision. Neither a good signature nor an unexpired date establishes that a credential is suitable for every use. The verifier also decides which issuers and claims it accepts.
Consider an illustrative university laboratory pass. Its signature verifies, but the student's access ends before the printed expiry date. A laboratory checking only the signature would accept an authentic but no longer acceptable pass. Conversely, cancelling a digital copy after key compromise need not erase the underlying qualification. When reading a credential system's documentation, identify the exact object whose status changes: the document, the account, or the real-world entitlement.
Treating these as interchangeable can produce incorrect access decisions and misleading explanations to users.
W3C's Bitstring Status List associates a credential with an index in a shared status list. For a single-bit revocation entry, a set bit marks revocation. The list is compressed and secured as a credential itself. The specification distinguishes irreversible revocation from reversible suspension and requires a minimum uncompressed list size of 16 KB. Bundling many entries avoids making each credential's status a unique network lookup.
A verifier must check the list's authenticity, purpose, validity and index before interpreting the bit. Fetching a shared list does not reveal a specific index to its server, but access timing can still be informative. Caching or accepting an appropriately fresh holder-supplied list can reduce contact with the issuer. Small effective groups, uniquely assigned lists, or colluding participants weaken the privacy benefit.
In an illustrative access system, record both the credential checked and the list version used; that makes a later disputed decision explainable without pretending that a compressed bitmap proves the issuer acted fairly.
Status and presentation freshness are separate checks. The Data Integrity specification provides domain and challenge fields that can bind a proof to an intended context and a particular interaction. A verifier supplied with an expected challenge must reject a proof carrying a different challenge. These mechanisms address replay; they do not replace the issuer's status mechanism or decide whether the holder is authorized for an action.
For a teaching exercise, imagine somebody captures yesterday's accepted presentation while the credential remains active today. Rechecking only revocation cannot identify that replay. A fresh challenge tied to the present transaction supplies the missing distinction, provided the chosen presentation protocol actually binds and verifies it. Write a verification trace with separate results for signature, expected domain, challenge, holder authorization and credential status.
If one result fails, the interface should explain that specific failure rather than report the vague and potentially false conclusion that the identity itself is invalid.
Certificate infrastructure offers a useful comparison. RFC 6960 defines OCSP responses with good, revoked and unknown states, and distinguishes the time a status was known from the time a response was produced. Its good status is not a universal assurance that a certificate was issued or is acceptable. This is an X.509 protocol, not the W3C credential format, but its precise separation of status and time exposes a common design mistake.
An illustrative verifier receives a signed status response from Monday on Wednesday. A valid signature says nothing by itself about whether Monday is recent enough for Wednesday's decision. Likewise, a timeout supplies no positive evidence of either revocation or continued validity. Specify how stale information, unavailable responders and unsupported status types are handled. A classroom badge and a privileged administrative credential may justify different availability choices.
Record those choices explicitly; changing a failure into an unconditional success is a policy decision, not a cryptographic conclusion.