Revocation

A Certificate Revocation List (CRL) is a centralized, time-stamped list of revoked credentials published by an issuer. Verifiers must fetch and check the latest list to confirm a credential's status.

• How it works: The issuer signs and periodically publishes a list of all revoked credential identifiers.
• Pros: Simple to implement, widely understood from traditional PKI.
• Cons: Introduces latency, requires constant list updates, and reveals all revoked IDs, creating a privacy leak.

Online status checking is a real-time, centralized query mechanism where a verifier contacts the issuer's server to check a credential's validity at the moment of verification.

• How it works: The verifier sends the credential's unique identifier to a pre-defined endpoint (e.g., via an API call).
• Pros: Provides instant, definitive revocation status.
• Cons: Requires the issuer's server to be always online, creates a direct link between the holder and issuer during verification (privacy concern), and is vulnerable to downtime.

A cryptographic accumulator is a space-efficient data structure that represents a set of credentials, allowing a prover to generate a succinct, zero-knowledge proof that a specific credential is not revoked, without revealing any other information.

• How it works: The issuer maintains an accumulator (e.g., a RSA or Merkle root) for all valid credentials. A revocation updates the accumulator. Holders get a witness proving membership.
• Pros: Enables privacy-preserving, offline verification. The verifier only needs the current accumulator root.
• Cons: Computationally intensive to update; requires careful management of witnesses upon revocation.

A Status List credential is a W3C Verifiable Credential standard that encodes revocation statuses for many credentials into a bitstring, which is itself issued as a signed, tamper-evident credential.

• How it works: Each credential is mapped to an index in a bitstring (0=valid, 1=revoked). The issuer publishes a signed StatusList2021 credential containing this bitstring.
• Pros: Decentralized verification; status can be cached. Aligns with existing VC infrastructure.
• Cons: The entire list must be fetched, and the holder's index position can potentially be correlated.

A smart contract registry is an on-chain, decentralized ledger where credential issuers record revocation events. Status is determined by querying the immutable contract state.

• How it works: The issuer calls a function on the smart contract to revoke a credential by its identifier (e.g., a hash). Verifiers query the same contract.
• Pros: Provides a transparent, censorship-resistant, and globally accessible source of truth. Enables permissionless verification.
• Cons: On-chain transactions incur gas fees for revocation actions. All revocation events are public, potentially exposing holder activity.

Time-based revocation uses cryptographic timelocks or credential expiration dates to automatically invalidate authorizations after a predetermined period, eliminating the need for active status checks.

• How it works: A credential contains an expirationDate field or is bound to a cryptographic primitive that becomes invalid after a certain block height or timestamp.
• Pros: Extremely simple for verifiers; no live check or list required. Predictable and automatic.
• Cons: Not suitable for revoking credentials before their natural expiry. Requires accurate time synchronization.

Smart contracts and decentralized applications (dApps) use revocation to manage dynamic permissions. Examples include:

• Revoking a user's minting rights or admin privileges.
• Invalidating an API key or session token for a decentralized service.
• Removing a delegate's voting power in a DAO governance system. This ensures that access rights can be updated in real-time without modifying the core contract logic.

Projects operating under regulatory frameworks use revocation to enforce sanctions or legal requirements. This can involve:

• Freezing assets or blacklisting addresses associated with illicit activity, as mandated by law.
• Revoking licenses or permissions for non-compliant participants in a regulated DeFi protocol.
• Invalidating tokens that are deemed securities if they fail to meet ongoing disclosure obligations.

Revocation mechanisms underpin subscription models and time-bound access in Web3. This includes:

• Automatically revoking access to a premium dApp feature when a subscription NFT expires or payment lapses.
• Terminating a user's stake in a liquidity pool and revoking their fee-earning rights upon withdrawal.
• Ending a validator's right to propose blocks if they are slashed for malicious behavior.

In systems where authority can be delegated—such as liquid staking or vote delegation—revocation allows principals to regain control. A token holder can revoke the voting power they delegated to another address. Similarly, a user can revoke the approval they granted to a staking pool contract, reclaiming direct control over their assets. This prevents indefinite, risky delegations.

A Certificate Revocation List (CRL) is a traditional, centralized method where a trusted authority publishes a signed list of revoked credential identifiers (e.g., serial numbers). Systems must check this list to verify a credential's validity. In blockchain contexts, CRLs can be published on-chain for transparency, but they reveal which specific credentials have been revoked, creating a privacy leak.

Cryptographic accumulators (e.g., RSA, Merkle trees) allow a prover to demonstrate membership or non-membership of an element in a set without revealing the set's contents. For revocation, a zero-knowledge proof (ZKP) can prove a credential's public key is not in the accumulator's revoked set. This provides strong privacy, as the verifier learns only the credential's validity, not its identity or the identities of other revoked users.

A simple, non-interactive revocation method where credentials contain a hard-coded expiry timestamp. Validity is checked against the current block time or timestamp. While privacy-preserving (no status checks needed), it lacks granularity for emergency revocations. It's often combined with other methods for a layered approach:

• Short-lived credentials reduce the attack window.
• Long-lived credentials require active revocation mechanisms.

Revocation is primarily a response to private key compromise. If a signing key is lost or stolen, any credential or authorization it controls must be revoked to prevent misuse. The core challenge in decentralized identity (e.g., Decentralized Identifiers / DIDs) is enabling the credential issuer or holder to revoke without relying on a central registry, while balancing privacy, immediacy, and system complexity.

Advanced credential systems like W3C Verifiable Credentials aim for selective disclosure (revealing only necessary attributes) and unlinkability (preventing correlation across uses). A poor revocation scheme can break these properties. For example, a unique identifier checked against a public revocation list allows tracking. Privacy-preserving revocation using ZKPs or accumulators is essential to maintain these security and privacy goals.