Revocation Registry

A revocation registry functions as an immutable, append-only ledger (often on a blockchain) that records the status of credentials. When a credential is revoked, a cryptographic proof of its invalidity—such as a revocation index or accumulator delta—is published to the registry. This creates a permanent, tamper-proof record that verifiers can query to check a credential's current validity state.

Advanced registries use cryptographic accumulators (like RSA accumulators or Merkle trees) to enable zero-knowledge proofs of non-revocation. This allows a holder to prove their credential is still valid without revealing its unique identifier or linking multiple presentations. This preserves unlinkability and minimal disclosure, key privacy principles of Self-Sovereign Identity (SSI).

Control over the registry is distributed to prevent a single point of failure or control. Governance models include:

• Issuer-Held: The credential issuer maintains their own registry.
• Ledger-Anchored: The registry state is anchored to a public blockchain (e.g., Ethereum, Sovrin).
• Holder-Mediated: The credential holder manages proof of non-revocation, often via a revocation status list in their digital wallet. This removes reliance on a central revocation authority.

To avoid requiring verifiers to download the entire registry history, systems generate compact state proofs. For a Merkle tree-based registry, this is a Merkle proof demonstrating that a credential's identifier is not in the tree's revoked leaves. For accumulator-based systems, it's a witness that proves membership in the valid set. These proofs are small and verifiable in constant time (O(1)).

Registries often incorporate time-based validity to automate revocation. Features include:

• Expiration Timestamps: Credentials auto-revoke after a set time.
• Status List Validity Periods: A revocation status list (like a W3C StatusList2021) is issued with a short validity window, requiring periodic refresh.
• Sliding Window Accumulators: The accumulator state updates at regular intervals (e.g., daily), and proofs are valid only for that period, forcing regular updates and limiting historical tracking.

To ensure cross-system functionality, revocation registries implement open standards. Key specifications include:

• W3C Verifiable Credentials: Defines the credentialStatus property for pointing to a revocation registry entry.
• W3C StatusList2021: A standard for bit-packed status lists (revocation or suspension).
• Hyperledger AnonCreds: Uses CL signatures and revocation registries on a distributed ledger.
• DIF Sidetree Protocol: Enables scalable Decentralized Identifiers (DIDs) with revocation capabilities.

The W3C Verifiable Credentials Data Model specification defines a standard credentialStatus property. This allows a credential to point to a revocation registry for status checks. Common implementations include:

• Status List 2021: Encodes revocation statuses into a compressed bitstring (like a bitmap) stored in a verifiable credential itself or on a public ledger.
• Revocation List 2020: A similar approach using JSON-LD and linked data proofs. This standard enables interoperability between different DID (Decentralized Identifier) methods and credential formats.

On Ethereum and other smart contract platforms, revocation registries are often implemented as smart contracts. These contracts maintain a mapping (e.g., from credential ID to status) that can be updated by the issuer and queried by verifiers. Key design patterns include:

• Merkle Tree Roots: Storing a root hash on-chain, with off-chain proofs for privacy.
• State Channels: Using layer-2 solutions for cheaper, faster status updates.
• ZKP Integration: Combining with zero-knowledge proofs (ZKPs) to allow proving non-revocation without revealing the credential ID.

Sovrin is a public utility permissioned ledger specifically designed for SSI. Its revocation registry implementation is built on the Hyperledger Indy codebase. It uses a cryptographic accumulator (a type of RSA accumulator) where the registry is a single, large number. Revoking a credential changes the accumulator value, and holders must obtain a new witness to prove their credential is still valid. This allows for constant-size proofs regardless of the number of revoked credentials.

Revocation registries enable real-world, revocable credentials:

• Employee Badges: A company can instantly revoke access credentials for a departed employee.
• University Diplomas: A university can revoke a degree if academic misconduct is discovered.
• Professional Licenses: Medical or financial licenses can be suspended by the issuing authority.
• KYC/AML Credentials: A DeFi protocol can check if a user's KYC credential from a provider is still valid before granting access, complying with regulatory requirements.

A revocation registry uses cryptographic accumulators (like RSA or Merkle trees) to represent a set of valid credentials. To prove a credential is still valid, a witness (a cryptographic proof) is generated, demonstrating the credential's inclusion in the accumulator. Revocation updates the accumulator, invalidating the witness for the revoked credential without revealing which specific credential was revoked.

Unlike a simple blacklist, a well-designed registry supports selective disclosure. A verifier can confirm a credential is not revoked without learning the credential's unique identifier or the holder's other credentials. This is achieved through zero-knowledge proofs (ZKPs) that prove the witness is valid for the current accumulator state, revealing nothing else.

• Registry Compromise: If the private key for an RSA accumulator is leaked, an attacker can forge valid witnesses or revoke arbitrary credentials.
• Witness Freshness Attacks: Using a stale witness to prove a revoked credential is still valid. Mitigated by requiring timestamps or linking to the latest accumulator state.
• Denial-of-Service via Registry Update: Malicious or frequent updates can burden credential holders who must constantly fetch new witnesses.
• Linkability: Poor implementation can allow verifiers to link multiple presentations from the same holder by tracking witness patterns.

Who controls the registry and how it's updated are critical design choices.

• Centralized Issuer Control: The credential issuer (e.g., a university) manages the registry. Simple but re-introduces a trusted party.
• Decentralized/Blockchain-Based: The registry's state (e.g., the accumulator root hash) is anchored on a blockchain, providing transparency and auditability of updates. However, update frequency must be balanced with on-chain costs.
• Holder-Local Updates: Credential holders periodically fetch delta updates to their witness, reducing issuer load but increasing holder responsibility.

Different accumulator types present trade-offs:

• RSA Accumulators: Provide constant-size witnesses and accumulator, but require a trusted setup and have computationally expensive updates.
• Merkle Tree Accumulators (e.g., CL Signatures): Witness size is logarithmic to the number of credentials. Updates are more efficient, but proofs are larger. No trusted setup required.
• Dynamic Accumulators: Allow efficient addition and deletion of members, crucial for a practical revocation system. The choice impacts system throughput, cost, and trust assumptions.

A privacy-enhancing feature that allows a credential holder to reveal only specific claims from a credential, without exposing the entire document. This is distinct from revocation.

• Mechanism: Uses zero-knowledge proofs or cryptographic blinding.
• Example: Proving you are over 21 from a driver's license without revealing your birth date or address.
• Interaction: Works in conjunction with revocation; a verifier checks both the disclosed claims and the credential's active status.

The authoritative entity that creates and cryptographically signs a Verifiable Credential. The issuer is responsible for maintaining the associated revocation registry.

• Key Role: Publishes the credential and its revocation status to the registry.
• Trust Anchor: The verifier's trust in the credential is rooted in trust of the issuer's DID and signing key.
• Obligation: Must operate the revocation registry infrastructure to update statuses.