Credential Revocation

A W3C Verifiable Credentials standard method where a credential's validity is checked against a published list of revoked credential IDs. The status list is a cryptographically signed bitstring where each bit represents the status (0=valid, 1=revoked) of a specific credential. This is highly efficient for batch verification and is the foundation for revocation registries.

A decentralized data structure, often stored on a blockchain or other verifiable data registry, that hosts the current status list. Issuers update this registry to revoke credentials. Verifiers query the registry's latest state. Using a blockchain provides tamper-evidence and auditability for all revocation actions, creating a public, immutable record.

An advanced cryptographic method using cryptographic accumulators (like RSA or bilinear map accumulators). The issuer adds all valid credential IDs to an accumulator and publishes a short witness. To revoke, the issuer updates the accumulator, invalidating the witness for the revoked credential. This provides constant-size proofs and enhanced privacy, as the verifier only sees a proof, not a full list.

Enables a holder to prove a credential is still valid without revealing the credential's unique identifier. This is critical for privacy-preserving systems. Using zero-knowledge proofs (ZKPs) or BBS+ signatures, the holder can generate a proof that their credential is not on the current revocation list, revealing only the necessary attributes (e.g., age > 21) while keeping the credential ID secret.

Two primary revocation triggers:

• Time-Based: A credential automatically expires at a set validUntil date. Simple but inflexible.
• Event-Based: Revocation is triggered by a specific event (e.g., employee termination, key compromise, credential misuse). This requires an active status check by the verifier against a revocation registry, providing real-time, granular control for the issuer.

Defines who controls the revocation data:

• Issuer-Held: The issuer hosts the status list on their server. Simple but creates a central point of failure and trust; the issuer can go offline or censor checks.
• Decentralized/Verifiable Data Registry: The status list is anchored to a public blockchain (e.g., Ethereum, Sovrin Ledger) or a decentralized storage network (e.g., IPFS). This ensures availability, censorship-resistance, and cryptographic verifiability of the revocation data's integrity.

Uses a cryptographic accumulator (like a RSA accumulator or Merkle tree) to create a compact, constant-size proof of non-revocation. The issuer maintains a registry of valid credentials. To prove a credential is not revoked, the holder provides a witness (proof) derived from the accumulator's current state. Revoking a credential requires updating the accumulator and invalidating old witnesses.

The verifier contacts the issuer's API endpoint directly to check a credential's status using a unique identifier. This is a centralized method, as it relies on the issuer's operational availability and introduces a point of failure. It offers real-time status but sacrifices the decentralized, offline-verifiable properties of other methods.

• Pros: Simple, real-time.
• Cons: Requires issuer availability, reveals verifier/holder activity to issuer.

Not revocation in the active sense, but a fundamental validity constraint. Every credential should have an expirationDate property. After this timestamp, the credential is considered invalid regardless of other status checks. This is a mandatory baseline control used in conjunction with active revocation methods to limit credential lifetime and reduce the burden of maintaining revocation lists indefinitely.

Revocation mechanisms must be designed to preserve privacy. A status check should not leak which specific credential a holder possesses to unrelated parties. Methods like bitstring status lists can be checked without revealing the credential's full ID if indexed pseudonymously. Zero-Knowledge Proofs (ZKPs) can prove a credential is in a valid set without revealing its position.

The W3C Status List 2021 specification defines a privacy-preserving revocation method using bitstring status lists. A credential points to a public, tamper-evident list (e.g., on a blockchain) where a single bit represents its revocation status. This allows verifiers to check status without revealing which specific credential they are validating, protecting user privacy. The list can be compressed and is designed for efficient, scalable revocation checks.

This cryptographic method uses cryptographic accumulators (like RSA or Merkle-tree based) to revoke credentials. The issuer maintains an accumulator representing all valid credentials. To revoke one, they update the accumulator witness. The prover must then update their credential's witness to prove it's still valid. This offers strong privacy (the verifier only sees a proof) but requires more complex state management and witness updates for the holder.

The simplest form of revocation is built-in expiration. Every Verifiable Credential contains an expirationDate property. After this timestamp, the credential is considered invalid. This is not revocation in the reactive sense but a proactive lifecycle control. It's often used in conjunction with other methods (like status lists) to limit the window of risk and automatically clean up stale credentials from the system.

Naive revocation can leak user data. If a verifier checks revocation by sending a credential's unique ID to a central service, it creates a correlation point, revealing when and where the user is presenting that credential. Effective methods like bitstring status lists are designed to be unlinkable—the verifier fetches the entire list, not querying for a specific ID. Ensuring revocation checks don't compromise privacy is a core design challenge.

Revocation mechanisms create a dependency on the issuer's continued operation or the availability of the status publication point (like a blockchain). If the status list host goes offline, valid credentials may appear revoked (false positives). Decentralized storage (e.g., IPFS) and blockchain anchoring improve resilience but introduce latency and cost considerations. The choice of revocation method directly impacts system liveness and trust assumptions.

Revocation interacts with Selective Disclosure techniques (e.g., BBS+ signatures). A user may disclose only a subset of claims from a credential. The revocation check must work even when the full credential identifier is not revealed. Some accumulator and status list methods support this by allowing proof of non-revocation for a blinded credential identifier, maintaining both minimal disclosure and revocation capability.

A revocation registry is a tamper-proof, decentralized data structure that maintains a list of revoked credential identifiers, such as credential hashes or public keys. Issuers update this registry to signal revocation, and verifiers check it during credential presentation. Common implementations use smart contracts on a blockchain or accumulators for privacy-preserving checks.

A Status List is a W3C Verifiable Credentials standard for a compact, privacy-preserving revocation mechanism. It encodes revocation statuses into a bitstring, where each bit corresponds to a specific credential. This list is itself issued as a Verifiable Credential, allowing verifiers to check a credential's status by inspecting a single, cryptographically verifiable bit without revealing which specific credential is being checked.

A cryptographic accumulator is a space-efficient data structure that can represent a set of values and provide membership/non-membership proofs. In revocation, it can prove a credential is not in a revoked set without revealing the set's contents. RSA accumulators and Merkle trees are common types, enabling zero-knowledge revocation checks where the verifier learns only the validity status, not the credential's specific identifier.

Selective disclosure is a privacy-enhancing feature that allows a holder to reveal only specific attributes or claims from a credential. It is closely related to revocation because a holder must also prove their credential is still valid (not revoked) without disclosing unnecessary information. This is often achieved using zero-knowledge proofs (ZKPs) in conjunction with revocation proofs.

Holder binding refers to cryptographic techniques that ensure a Verifiable Credential can only be used by its legitimate holder, preventing unauthorized presentation. Strong holder binding (e.g., using DPoP or biometric keys) is a preventative security measure that reduces the attack surface and, consequently, the need for revocation. If a credential is strongly bound, theft becomes significantly harder.

A Verifiable Credential is a tamper-evident, cryptographically secure digital credential formatted according to the W3C standard. Revocation is a core requirement for practical VC systems, as the credential's verifiable status—proof it has not been revoked by its issuer—is a mandatory check during the verification process. The credential's metadata often points to its associated revocation mechanism.