Revocation List

In Decentralized Identifier (DID) systems, a revocation list is used to invalidate Verifiable Credentials without requiring the issuer to be online. For example, if a user's digital driver's license private key is compromised, the issuer can add the credential's ID to a Status List 2021 entry, preventing its future verification. This mechanism is a core component of the W3C Verifiable Credentials Data Model.

In traditional web security, Certificate Transparency (CT) logs function as a public, append-only revocation list for TLS/SSL certificates. When a Certificate Authority (CA) mistakenly or maliciously issues a certificate, it can be reported and added to a CT log's list of suspect certificates. Browsers and operating systems monitor these logs to reject certificates that have been publicly revoked, enhancing trust in the Public Key Infrastructure (PKI).

Decentralized Finance protocols use revocation lists for role-based access control. For instance, a DAO's smart contract may manage a list of wallet addresses that are banned from certain functions (e.g., executing treasury transactions). Adding an address to the on-chain revocation list immediately prevents it from calling privileged functions, providing a real-time security measure against malicious actors or compromised multisig signers.

A primary use case is managing compromised private keys. If a user suspects their cryptographic key for a blockchain wallet or signing authority has been exposed, the associated public key or credential can be added to a revocation list. Any system verifying signatures from that key will first check the list, rejecting transactions or assertions signed after the revocation timestamp. This is a foundational security practice in public key infrastructure.

Organizations use revocation lists to meet regulatory compliance (e.g., GDPR's "right to be forgotten", sanctions lists). A company issuing employee access badges can maintain a revocation list of badge IDs for terminated staff. Systems at secure entrances check this list in real-time to deny access. In blockchain, a token issuer might maintain a list of wallet addresses subject to legal sanctions, preventing them from holding or transferring the asset.

The W3C Status List 2021 specification provides a standardized, space-efficient method for revocation. It uses a bitstring where each bit represents the status (0=valid, 1=revoked) of a credential. The issuer signs this compressed bitstring and publishes it, often on a blockchain or decentralized storage. Verifiers fetch the list, check the bit at the credential's index, and cryptographically verify the issuer's signature, enabling scalable, privacy-preserving revocation checks.

In Verifiable Credentials (VCs) and Decentralized Identity (DID) ecosystems, a revocation list is used to check if a credential (like a digital driver's license or university degree) is still valid. Issuers publish a list of revoked credential IDs (e.g., on a blockchain), allowing verifiers to instantly check status without contacting the issuer directly. This is essential for privacy-preserving and offline-capable trust systems.

For security tokens and regulated digital assets, revocation lists enforce compliance. If a token holder is found to be in violation of regulations (e.g., sanctions), their token's unique identifier can be added to a revocation list managed by a compliance oracle or regulator. This prevents the transfer or use of the token, embedding regulatory logic directly into the asset's programmable layer.

Revocation lists are used in decentralized access control systems, such as those governing DAO membership or gated content. A list of revoked public keys or session tokens is maintained, often via a smart contract or a cryptographic accumulator. This allows systems to instantly invalidate access for specific entities without needing to update permissions for all valid users.

Blockchains provide an ideal, immutable anchor for revocation lists. The list's cryptographic hash (like a Merkle root) is periodically published on-chain, providing a globally consistent and tamper-proof reference point. Systems like Ethereum or Hyperledger Indy use this pattern to ensure all parties can verify the current, authoritative state of revocations without relying on a single database.

Advanced schemes like zero-knowledge revocation allow a verifier to confirm a credential is not revoked without learning which specific credential ID is being checked. This is achieved using cryptographic accumulators (e.g., RSA or Merkle tree-based) or zk-SNARKs, enhancing privacy by preventing correlation between different presentations of the same credential.

A revocation list's primary function is to act as a denylist or blocklist, providing a real-time, authoritative source for checking if a previously issued credential (like a token, certificate, or key) is no longer valid. This is essential for responding to security incidents like key compromise, credential theft, or user privilege changes. Without it, compromised assets remain active, creating a critical security vulnerability.

Revocation implementations vary by trust model:

• Centralized Lists: Managed by a single authority (e.g., a Certificate Authority's CRL). Fast to update but creates a single point of failure and control.
• On-Chain Lists: Stored on a blockchain (e.g., an ERC-20 blacklist). Tamper-proof and transparent, but updates are slower and incur transaction costs.
• Zero-Knowledge Proof Lists: Status is proven without revealing the revoked item (e.g., in anonymous credentials). Maximizes privacy but adds cryptographic complexity.

This is a fundamental security trade-off in distributed systems using revocation lists. Liveness ensures all nodes eventually see the latest list. Consistency ensures all nodes see the same list at the same time. A network may prioritize one over the other:

• Favoring liveness risks temporary forks where a revoked asset is accepted on some nodes.
• Favoring consistency can cause delays in propagating critical revocations, creating a window of vulnerability.

Simple revocation lists can leak sensitive metadata. If a verifier checks for a specific user's credential on a public list, it reveals that the user is interacting with that service. Advanced schemes like accumulators or zero-knowledge proofs allow a prover to demonstrate their credential is not on the list without revealing which credential they hold, preserving user privacy during the verification process.

Common vulnerabilities stem from flawed logic or integration:

• Time-of-Check Time-of-Use (TOCTOU): The state of the list changes between the time it's checked and the time the credential is used.
• Unenforced Checks: The application fails to query the revocation list for every transaction.
• Sybil Attacks on Decentralized Lists: An attacker floods the list with junk entries to increase verification cost or obscure genuine revocations.
• Centralized Point of Failure: The list manager can censor updates or be compromised.

An allowlist is the security inverse of a revocation list. Instead of listing what is banned, it explicitly lists only what is permitted. This default-deny model is often considered more secure for high-value systems, as any new, unknown, or compromised asset is blocked by default. The choice between allowlisting and denylisting is a key architectural decision based on the required security posture and operational overhead.

Credential Status is a property within a Verifiable Credential that points to the mechanism for checking its revocation or suspension state. It is the field that links a VC to a revocation list.

• Property: Appears in the VC's credentialStatus object.
• Information: Contains the id (URL of the list), type (e.g., StatusList2021Entry), and the credential's specific statusListIndex.
• Function: Allows a verifier to programmatically locate and check the credential's current status.

A Certificate Revocation List is the traditional PKI (Public Key Infrastructure) analogue to a blockchain revocation list. It is a signed list of serial numbers for digital certificates that have been revoked before their expiration date.

• Legacy System: Used extensively in TLS/SSL for websites and code signing.
• Centralized Model: Issued and signed by a centralized Certificate Authority (CA).
• Contrast: Unlike decentralized status lists, CRLs are part of a hierarchical, permissioned trust model.

Selective Disclosure is a privacy-enhancing feature that allows the holder of a Verifiable Credential to reveal only specific claims from it, without exposing the entire document. Revocation checks must respect this principle.

• Techniques: Enabled by cryptographic methods like BBS+ signatures or zero-knowledge proofs.
• Privacy: Prevents data minimization, allowing a user to prove they are over 21 without revealing their birth date.
• Interaction: A revocation check for a partially disclosed credential must not leak extra information about the holder or other claims.