Credential Status Registry

A Credential Status Registry enables issuers to revoke a Verifiable Credential without contacting the holder, by updating a decentralized status list (e.g., a revocation registry on a blockchain). This allows verifiers to check the credential's active status in real-time against a tamper-proof source of truth, moving away from centralized certificate revocation lists (CRLs).

The registry's integrity is secured through cryptographic commitments, often using Merkle trees or direct on-chain storage. The status of credentials is represented as bits in a status list, where a 1 typically indicates revoked and a 0 indicates valid. The cryptographic root of this list is published to a verifiable data registry, such as a blockchain, ensuring the data cannot be altered retroactively.

Advanced registries support privacy-preserving status checks. Using techniques like bitstring status lists and zero-knowledge proofs, a verifier can confirm a credential is not revoked without learning the holder's specific identifier or the status of other credentials in the registry. This prevents correlation and protects user privacy during verification.

These registries are built on open W3C standards, primarily the Verifiable Credentials Data Model. Key specifications include:

• Status List 2021: A standard for encoding revocation status in a compressed bitstring.
• Linked Data Proofs: For cryptographically signing the status list. This standardization ensures credentials and their status checks work across different issuers, holders, and verifiers.

To manage blockchain gas costs and latency, registries use optimizations like:

• Batching: Aggregating status updates for many credentials into a single transaction.
• Off-Chain Storage with On-Chain Anchors: Storing the large status list off-chain (e.g., on IPFS) while publishing only its cryptographic hash on-chain.
• Sparse Merkle Trees: Enabling efficient proofs for large registries where only a small fraction of credentials are revoked.

The Indy-Claims Registry used in Hyperledger Indy/Sovrin networks is a canonical example. It uses a revocable credential design where an issuer creates a revocation registry on the ledger. Each credential issuance receives a credential revocation identifier (CRED_ID). Revocation involves posting a cryptographic accumulator delta to the ledger, which verifiers use to compute the current, non-revoked state.

The primary function is to allow verifiers to check if a previously issued credential has been revoked by its issuer. Instead of contacting the issuer directly, the verifier queries the registry's smart contract. This is essential for credentials that represent permissions, memberships, or certifications that can expire or be withdrawn.

• On-Chain Lookup: The registry stores a mapping (e.g., credential ID → status) on a blockchain.
• Status Values: Typically returns active, revoked, or suspended.
• Gas Efficiency: Optimized registries use bitmaps or merkle trees to batch updates and minimize gas costs for checks.

Registries are implemented either as standalone smart contracts or via off-chain indexers with on-chain anchoring.

• On-Chain Registry: A smart contract (e.g., an EAS Schema Registry) maintains a direct mapping. Status checks are simple contract calls but update costs are borne by the issuer.
• Off-Chain with Anchors: Status lists are maintained off-chain (e.g., in a JSON file), and a cryptographic commitment (like a Merkle root) is periodically published on-chain. Verifiers fetch the off-chain proof and verify it against the on-chain root. This model is used in W3C Status List 2021.

EAS implements a credential status registry natively within its smart contract system. When an attestation (credential) is created, it is assigned a unique UID.

• Revocation Function: The original attester (or a designated revoker) calls revoke(uid) on the EAS contract, which flips a boolean in the on-chain record.
• Verification: Any verifier can call getAttestation(uid) to retrieve the attestation data and its revoked status in a single, atomic query.
• Gas Costs: The issuer pays gas to revoke, but the verifier's check is a simple, low-cost view function call.

SBTs representing qualifications, licenses, or access rights require a revocation mechanism. A status registry allows the issuing organization to invalidate the SBT without burning the NFT, preserving its historical record.

• DAO Membership: A DAO can issue a membership SBT and revoke it if a member violates rules.
• Professional Licenses: A licensing body issues an SBT credential. If the license is suspended, they revoke it in the registry, making it instantly verifiable by employers or platforms.
• Preserving History: The SBT remains in the holder's wallet as a record, but its revoked status is clearly indicated by the registry.

While a Credential Status Registry manages the lifecycle of individual credentials, a Trust Registry is a complementary system that manages the authority of issuers themselves.

• Scope: A Trust Registry lists which decentralized identifiers (DIDs) or smart contract addresses are authorized to issue credentials for a specific schema or context.
• Hierarchical Trust: Verifiers check both the Trust Registry (is the issuer trusted?) and the Status Registry (is this specific credential valid?).
• Example: The Ethereum Attestation Service Schema Registry acts as a hybrid, recording which schemas exist and which addresses are authorized to make attestations for them.

Different architectures for invalidating credentials, each with distinct security properties.

• Accumulators (e.g., RSA, Merkle Trees): Enable privacy-preserving revocation by proving non-membership in a revocation set without revealing the set's contents.
• Status Lists (e.g., Bitstring, Indexed): Simpler to implement but can leak metadata; a verifier checks if a credential's unique identifier appears on a public list.
• On-Chain Registries: Provide strong auditability and censorship resistance but may expose transaction patterns and require gas fees for updates.

Techniques that allow a verifier to confirm credential status without learning unnecessary information.

• Zero-Knowledge Proofs (ZKPs): A holder proves their credential is valid (e.g., not revoked) without revealing its identifier or the contents of the revocation registry.
• Selective Disclosure: The holder reveals only the specific claim (e.g., "over 21") and a proof of its current validity, not the entire credential.
• Blind Signatures: Used in some schemes to allow issuance without the issuer learning the credential's future unique identifier.

Key security threats to credential status systems and how to defend against them.

• Linkability: Correlating multiple verifications of the same credential. Mitigated using unlinkable proofs and rotating identifiers.
• Denial-of-Service (DoS) on Registry: Targeting the availability of the status source. Mitigated by using decentralized or replicated storage (e.g., IPFS, blockchain).
• Malicious Revocation: An issuer improperly revoking a valid credential. Mitigated by implementing governance controls, timelocks, or immutable issuance.
• Replay Attacks: Using an old validity proof. Mitigated by including timestamps or nonces in the proof.

The trade-off between removing central points of failure and establishing trust in the registry's operation.

• Fully Decentralized (e.g., Blockchain): Status is written to a public ledger. Trust is placed in the network's consensus rules and the immutability of the chain.
• Federated: A consortium of trusted entities operates the registry. Trust is distributed but requires governance among known parties.
• Centralized: A single entity controls issuance and revocation. Creates a single point of failure and censorship but is often simplest to deploy. The choice impacts censorship resistance, availability, and auditability.

How credential status mechanisms align with privacy regulations like the General Data Protection Regulation (GDPR).

• Right to Erasure (Article 17): A core challenge. Revocation is not erasure. Systems must distinguish between invalidating a credential and deleting personal data from the issuer's records.
• Data Minimization (Article 5): Privacy-preserving verification (using ZKPs) is inherently compliant, as it discloses the minimum necessary data.
• Controller/Processor Roles: The status registry operator may be a data processor. Clear legal agreements are required to define responsibilities for the personal data (identifiers) potentially exposed on-chain.

The foundational data model for digital credentials. A Verifiable Credential is a tamper-evident, cryptographically signed attestation (like a digital driver's license) issued by an authority. A Credential Status Registry is used to check the revocation status of a VC without contacting the issuer directly, a process essential for maintaining user privacy and system decentralization.

• Standard: Defined by the W3C Verifiable Credentials Data Model.
• Structure: Contains claims, issuer metadata, proof of issuance, and a status field pointing to a registry.

A globally unique, cryptographically verifiable identifier controlled by the subject (user, organization, or thing). DIDs are the 'from' and 'to' addresses for Verifiable Credentials. A Credential Status Registry itself is often identified and resolved via a DID, and DIDs are used to authenticate updates to the registry (e.g., revoking a credential).

• Function: Enables self-sovereign identity without central registries.
• Relation: The registry's controller uses their DID's private key to authorize status list updates.

A specific, efficient implementation of a Credential Status Registry defined in the W3C VC Status List 2021 specification. Instead of a simple on/off list, it uses a compressed bitstring where each bit represents the revocation status (e.g., 0=valid, 1=revoked) of a single credential. This allows a single, small status list file to manage the status of thousands of credentials.

• Efficiency: Dramatically reduces data size and bandwidth.
• Privacy: Status checks can be done without revealing which specific credential is being validated.

A synonym often used in specific frameworks like Hyperledger Indy and Aries. A Revocation Registry is a type of Credential Status Registry that uses a cryptographic accumulator (like a CL signature) to enable selective, privacy-preserving proof of non-revocation. The prover can generate a zero-knowledge proof that their credential is still valid without revealing its unique identifier.

• Key Feature: Enables anonymous credential systems.
• Technology: Often built on CL signatures or similar cryptographic accumulators.

The broader infrastructure layer where DIDs and status information are anchored. As defined by W3C, a Verifiable Data Registry is a system that mediates the creation and verification of identifiers, keys, and other relevant data, such as credential schemas and revocation registries. A Credential Status Registry is a specific application hosted on a Verifiable Data Registry like a blockchain or a specialized distributed ledger.

• Examples: Ethereum (for Ethereum DIDs), Sovrin Ledger, ION (Bitcoin).
• Role: Provides the decentralized, trusted root for registry data.

A core privacy-enhancing capability of Verifiable Credential systems that relies on a functional status registry. Selective Disclosure allows a holder to reveal only specific claims from a credential (e.g., just your over-21 status from a driver's license) while keeping the rest private. A status check must be possible on this partially disclosed credential without compromising the holder's privacy, which is why privacy-preserving registries (like bitstring or accumulator-based) are critical.

• Privacy Goal: Minimize data exposure.
• Dependency: Requires status checks that do not leak credential identifiers.