Revocation Registry

A cryptographic accumulator aggregates a set of valid credential identifiers into a single fixed-size value, enabling efficient membership proofs. Unlike bitstring-based registries, accumulators support zero-knowledge proofs that a credential is not revoked without revealing which credential is being checked.

• RSA Accumulators: Use modular exponentiation to prove non-revocation with constant-size witnesses
• Elliptic Curve Accumulators: Provide shorter proofs and faster verification than RSA variants
• Dynamic Accumulators: Support adding and deleting values without recomputing the entire structure

This approach is fundamental to AnonCreds and privacy-preserving identity systems where correlation must be prevented.

A bitstring status list encodes revocation states as a compressed sequence of bits, where each bit position corresponds to a specific credential index. This mechanism, standardized in the W3C Bitstring Status List v1.0, allows verifiers to check revocation status without contacting the issuer directly.

• Each credential is assigned an index within a bitstring of configurable size (typically 16KB to 256KB)
• A bit value of 1 indicates revocation; 0 indicates validity
• The bitstring is published at a publicly accessible URL and referenced in the credential's credentialStatus property
• Supports suspension and revocation as distinct states using multiple bitstrings

This approach is highly efficient for high-volume credential ecosystems where accumulator witness updates would be impractical.

Revocation registries must enable status verification without creating correlatable identifiers that could link a credential holder's activities across different verifiers. Privacy-preserving mechanisms ensure that checking revocation does not leak metadata about the holder.

• Non-Correlation: Verifiers cannot link multiple status checks to the same credential or holder
• Unlinkable Presentations: Each presentation generates a fresh proof that does not reveal the credential's index in the registry
• Anonymous Revocation: Using zero-knowledge proofs, a holder can demonstrate non-revocation without disclosing which credential they hold
• Decentralized Hosting: Registries can be hosted on distributed ledgers or content-addressable networks to prevent tracking by a single infrastructure provider

These properties are essential for Self-Sovereign Identity systems operating under GDPR and similar privacy regulations.

Only the credential issuer possesses the cryptographic authority to update the revocation status of credentials they have issued. This authority is enforced through digital signatures tied to the issuer's DID Document and its associated public keys.

• Signed Status Updates: Every modification to the registry is cryptographically signed by the issuer's private key
• Key Rotation Support: Issuers can rotate signing keys without invalidating existing credentials, provided the DID Document is updated
• Delegated Revocation: Some architectures allow the issuer to delegate revocation authority to a designated third party while maintaining audit trails
• Immutable Audit Logs: When anchored to a distributed ledger, every revocation event creates a tamper-evident, timestamped record

This ensures that no unauthorized party can revoke a credential, maintaining the integrity of the trust framework.

To reduce latency and external network dependencies, verifiers can maintain local caches of revocation registries. This is critical for offline-first scenarios and high-throughput verification systems.

• Delta Updates: Verifiers fetch only the changes since their last synchronization, minimizing bandwidth
• Time-to-Live (TTL): Cached registries include expiration metadata to ensure verifiers do not rely on stale revocation data
• Bloom Filters: Probabilistic data structures can provide fast, space-efficient pre-checks before querying the full registry
• Content-Addressable Storage: Registries stored on IPFS or similar networks allow verifiers to retrieve data from the nearest node

Caching strategies must balance freshness guarantees against performance requirements, especially in environments with intermittent connectivity.

The technical operation of a revocation registry is governed by a trust framework that defines the legal and operational rules for issuers, holders, and verifiers within an ecosystem.

• Accreditation: Only issuers certified by a Trust Registry are authorized to write to the revocation registry
• Service Level Agreements: Define uptime, latency, and data persistence requirements for registry infrastructure
• Jurisdictional Compliance: Registries must comply with data residency laws, often requiring geographically distributed hosting
• Ecosystem-Specific Schemas: Governance authorities define which credential types and revocation states are supported

Frameworks like the Trust over IP (ToIP) Foundation stack separate technical governance from business governance, ensuring that revocation registries operate within legally enforceable boundaries.