Revocation Registry Definition

A revocation registry functions as a publicly accessible ledger (often a blockchain or a verifiable data registry) that maintains a list of revoked credential identifiers. It uses cryptographic accumulators (like RSA or Merkle trees) to enable efficient, privacy-preserving proofs. A verifier can check a revocation status proof against the registry's current state to confirm a credential is still valid, without learning which specific credential is being checked.

Two primary cryptographic structures are used:

• RSA Accumulators: Represent the set of valid credentials as a single, constant-size value. Revoking a credential requires updating a witness for all other holders.
• Merkle Tree (CL) Accumulators: Represent valid credentials as leaves in a Merkle tree. The root is published to the registry. Revocation removes a leaf, requiring an updated proof for the non-revoked subset. This method is more common in W3C-compliant systems like AnonCreds.

The registry enables selective disclosure of revocation status. A holder generates a zero-knowledge proof (ZKP) that their credential's unique identifier (e.g., a credential index) is not in the published revocation list, without revealing the identifier itself. This prevents correlation across different verifications and is a cornerstone of self-sovereign identity (SSI) architectures.

Key lifecycle operations managed by the issuer or a designated entity:

• Issuance: Adding a new credential identifier to the accumulator and providing the holder with an initial validity witness.
• Revocation: Updating the accumulator to exclude a credential's identifier and publishing the new state (e.g., a new Merkle root).
• Update: Distributing witness update information to all non-revoked holders so they can refresh their proofs.

Standardized frameworks define how registries are built and used:

• Hyperledger AnonCreds: Uses a CL-signature-based scheme with a Merkle tree accumulator, often anchored to an Indy ledger.
• W3C Verifiable Credentials Data Integrity: Specifies the statusList2021 method, which can use bitstring status lists (less private) or cryptographic accumulators.
• JSON Web Token (JWT) Credentials: Often rely on simpler, non-private methods like querying a URL for a revocation list.

Design choices involve key trade-offs:

• Privacy vs. Efficiency: Accumulators provide privacy but require witness updates for non-revoked holders. Public lists are simpler but leak data.
• Decentralization: A registry's resilience depends on its hosting. Blockchain-anchored registries are tamper-proof but may have higher latency and cost.
• Scalability: The frequency of revocations and the number of holders impact the overhead of witness updates and proof generation.

A revocation registry is a cryptographically secure, on-chain or off-chain data structure that tracks the revocation status of verifiable credentials (VCs). Its primary purpose is to allow an issuer to invalidate a credential (e.g., a driver's license or membership card) while enabling a verifier to check its status without learning any other information about the credential holder. This is a fundamental requirement for functional, real-world credential systems.

Modern systems like those in W3C Verifiable Credentials often use cryptographic accumulators (e.g., RSA Accumulators, CL Signatures).

• The issuer publishes a revocation registry containing a cryptographic accumulator value.
• Each issued credential gets a unique, private witness.
• To revoke, the issuer updates the accumulator, invalidating the witness for that credential.
• A verifier checks a credential's proof against the current accumulator state.
• This allows for selective disclosure and status checks without correlatable on-chain transactions.

Revocation data can be stored in different locations with trade-offs:

• On-Chain (e.g., Ethereum, Sovrin): Provides tamper-proof, globally available status lists. Can be expensive and expose metadata.
• Off-Chain / Decentralized Storage (e.g., IPFS): More private and cost-effective, but requires verifiers to fetch data from a potentially mutable source.
• Hybrid Approaches: The registry's root hash (e.g., a Merkle root) is anchored on-chain for integrity, while the detailed data lives off-chain.

A well-designed revocation registry minimizes privacy leaks:

• Unlinkability: Checking the status of two different credentials should not reveal they belong to the same holder.
• Minimal Disclosure: The verifier learns only 'valid' or 'revoked,' not the credential's contents or holder identity.
• Non-Correlation: Sequential status checks for the same credential should not be linkable to each other by the registry maintainer or observers.

Implementing revocation registries involves navigating several technical hurdles:

• Scalability: Managing registries for millions of credentials without excessive gas costs or data bloat.
• Update Frequency & Latency: Balancing the need for instant revocation with the performance of the underlying blockchain or storage layer.
• Governance: Defining who can update the registry (often just the issuer) and under what conditions.
• Interoperability: Ensuring different systems (e.g., Hyperledger Indy, Ethereum-based systems) can interpret each other's revocation status.

A revocation registry is a tamper-evident data structure, often implemented as a Merkle tree on a blockchain, that allows an issuer to revoke a specific verifiable credential without revealing which credential was revoked. The registry publishes cryptographic accumulators (like a root hash) that allow a verifier to check a credential's status using a zero-knowledge proof, ensuring privacy and selective disclosure.

The W3C Verifiable Credentials Data Model defines a standard interface for revocation. Common implementations include:

• Status List 2021: Encodes revocation statuses in a compressed bitstring, with the credential pointing to a specific index.
• Revocation List 2020: An earlier JSON-based list of revoked credential IDs.
• Bitstring Status List: A space-efficient method where each bit represents the status of a credential, enabling batched updates to the registry.

To prevent correlation, verifiers do not query the registry directly with a credential ID. Instead, the holder provides a cryptographic non-interactive proof (e.g., a zk-SNARK or zk-STARK) derived from the registry's current state. This proof demonstrates that their credential's unique identifier is not on the revocation list, without revealing the identifier itself to the verifier or the registry.

While the registry data can be stored off-chain, its root hash or accumulator state is typically anchored to a blockchain (e.g., Ethereum, Hyperledger Indy) to provide global availability, immutability, and auditability. This makes the registry's state cryptographically verifiable by all parties. Smart contracts can manage registry updates, ensuring only the authorized issuer can revoke credentials.

The issuer holds a revocation key to authorize updates. Revoking a credential involves:

1. Updating the private accumulator state.
2. Publishing a new revocation registry entry (e.g., a new Merkle root) to the verifiable data registry.
3. Providing witnesses or delta updates to non-revoked holders so they can generate fresh proofs. Systems must handle the key compromise scenario, often through a separate revocation authority or time-based key rotation.

In SSI ecosystems like those built on Hyperledger Aries, revocation registries are essential for real-world credentials:

• Diplomas: A university can revoke a degree if fraud is discovered.
• Professional Licenses: A medical board can suspend a doctor's license.
• Access Credentials: A company can revoke an employee's building access upon termination. This allows trust to be dynamically managed without recreating the entire credential system.

A digitally signed, tamper-evident credential whose authorship and integrity can be cryptographically verified. It is the primary object whose revocation status is tracked by a revocation registry. VCs contain claims (e.g., 'over 21') issued by an issuer to a holder.

• Structure: Contains metadata, claims, and proofs.
• Standard: Defined by the W3C Verifiable Credentials Data Model.

A self-sovereign identifier controlled by the subject (e.g., a user or organization) without reliance on a central registry. DIDs are often the subject of a Verifiable Credential and the issuer of a revocation registry.

• Format: did:method:identifier (e.g., did:ethr:0x...).
• Control: Proven via cryptographic keys, not a central authority.

The property of a Verifiable Credential that indicates whether it is currently valid, suspended, or revoked. The revocation registry is the mechanism that publishes this status.

• Status List Entry: A bit in a status list (often in the registry) representing the credential's state (0=valid, 1=revoked).
• Check: Verifiers query the registry's status list to confirm the credential has not been revoked.

The core data structure within a revocation registry, typically a compressed bitstring where each bit corresponds to the status of a single credential. This enables efficient, scalable revocation checks.

• Efficiency: A single on-chain transaction or registry update can revoke thousands of credentials.
• Compression: Bits are often encoded into a Base64 string to minimize storage and transmission size.

The entity that requests and checks a Verifiable Credential from a holder. The verifier's trust in the credential depends on checking its digital signature, schema, and—critically—querying the relevant revocation registry to ensure the credential is still active.

• Trust Triangle: Completes the issuer-holder-verifier model.
• Zero-Knowledge: Advanced systems allow verifiers to check revocation status without learning which specific credential was presented.

An advanced cryptographic alternative to a simple status list. It allows a issuer to prove a credential is not in a revoked set without revealing the entire set or the specific credential index. Common types include RSA Accumulators and Merkle Tree-based accumulators.

• Privacy-Preserving: Enables selective disclosure of non-revocation.
• Computational Overhead: More complex to implement than a simple bitstring.

A revocation registry is a tamper-proof, decentralized data structure that maintains a list of revoked credential statuses. It allows verifiers to check if a Verifiable Credential (VC) or Decentralized Identifier (DID) is still valid without contacting the issuer directly. This is typically implemented using accumulators (like cryptographic accumulators or sparse Merkle trees) to provide privacy-preserving proofs of non-revocation.

Modern registries use zero-knowledge techniques to allow a user to prove their credential is not on the revocation list without revealing which credential they hold. Key methods include:

• Revocation Bitmaps: A list where each credential corresponds to a bit; a ZK-proof shows the user's bit is 0 (not revoked).
• Sparse Merkle Trees: The user provides a Merkle proof of inclusion for a non-revoked leaf.
• Accumulators: The issuer provides a witness for valid credentials; revocation destroys this witness.

Control over the registry determines system trust assumptions. Common models are:

• Issuer-Held: The credential issuer maintains and updates the registry (common in W3C Verifiable Credentials).
• Ledger-Based: The registry is anchored to a public blockchain (e.g., Hyperledger Indy, Ethereum), providing decentralized availability and auditability.
• Holder-Mediated: The credential holder fetches and presents a non-revocation proof from the registry, reducing issuer dependency post-issuance.

The design of a revocation registry directly impacts system security and privacy.

• Availability Risk: If the registry is offline, verification fails. Decentralized storage mitigates this.
• Privacy Leaks: Naive implementations can leak credential identifiers or correlation patterns during status checks.
• Issuer Trust: In issuer-held models, the issuer remains a trusted party for revocation status, a potential centralization point.
• Update Latency: The time between revocation and its reflection in the registry creates a window of vulnerability.

Real-world systems implement revocation registries in specific ways:

• Hyperledger Indy/AnonCreds: Uses a revocation registry built on a CL signature accumulator, published to the Indy ledger.
• W3C Status List 2021: Encodes revocation statuses in a bitstring (bitmap) stored in a credentialStatus field, often hosted on HTTP(S) endpoints.
• Ethereum Attestation Service (EAS): Uses on-chain revocation transactions to invalidate specific attestations, with the registry being the blockchain state itself.

Understanding revocation requires familiarity with adjacent identity primitives:

• Verifiable Credential (VC): The digital, cryptographically-signed attestation whose status is being checked.
• Decentralized Identifier (DID): The identifier for the subject of the credential, often referenced in revocation checks.
• Selective Disclosure: The ability to reveal only specific claims from a VC, which revocation checks must not compromise.
• Trust Registry: A separate list of authorized issuers, distinct from a revocation registry for invalid credentials.