Off-Chain Revocation

A W3C Verifiable Credential that contains a cryptographically signed bitstring where each bit represents the revocation status of a specific credential. The issuer signs this list off-chain, and verifiers check a credential's unique index against it.

• Bitstring: A compact array of bits (0=valid, 1=revoked).
• Signed Status List: The issuer's signature ensures the list's integrity and authenticity.
• Credential Binding: Each issued credential contains a statusListIndex pointing to its specific bit.

To prove a credential's validity, a cryptographic proof is generated off-chain, demonstrating that the bit at the credential's statusListIndex is 0 (not revoked). This proof, not the full status list, is shared with the verifier.

• Zero-Knowledge Elements: Advanced schemes can prove a bit is 0 without revealing the status of other credentials.
• Selective Disclosure: The verifier learns only the status of the specific credential in question.
• Efficiency: The proof is small and quick to verify compared to fetching and parsing a full list.

The signed status list must be made available at a public, persistent URI that all parties can access. While not on the blockchain's execution layer, it's often hosted on decentralized storage networks to ensure censorship resistance and availability.

• Common Hosting Solutions: IPFS, Arweave, or decentralized web nodes (DWNs).
• URI in Credential: The credential's statusListCredential property points to this URI.
• Availability Guarantee: Decentralized storage prevents a single issuer server from being a point of failure or control.

A core advantage is enabling privacy-preserving verification. The holder can prove their credential is valid without revealing its unique identifier or the status of unrelated credentials.

• No Correlation: Verifiers cannot link multiple presentations from the same holder via a shared status list call.
• Minimal Information: Only the necessary proof is disclosed, aligning with data minimization principles.
• Holder Control: The holder manages the proof generation and disclosure process.

This method dramatically reduces gas fees and blockchain bloat compared to on-chain revocation registries (e.g., smart contract mappings). Status updates are off-chain transactions, not blockchain transactions.

• Issuer Cost: Updating a status list is a simple, low-cost off-chain operation.
• Network Load: Does not consume blockchain block space for status changes.
• Scalability: Supports high-volume issuance and revocation use cases (e.g., event tickets, employee badges) that would be prohibitively expensive on-chain.

The verifier's process involves fetching and cryptographically verifying data from multiple sources to establish trust.

1. Fetch Status List: Retrieve the statusListCredential from its URI.
2. Verify Issuer Signature: Cryptographically validate the issuer's signature on the status list.
3. Check Proof or Bit: Verify the provided bitstring proof or, in simpler implementations, check the bit at the statusListIndex.
4. Establish Freshness: Ensure the status list is sufficiently recent (e.g., by checking its issuance date) to trust its validity.

A revocation registry is a cryptographically secured, off-chain data structure (often a Merkle tree) that maintains a list of revoked credential identifiers. The verifier checks a compact revocation status list or a cryptographic non-inclusion proof (e.g., a Merkle proof) to confirm the credential is still valid without learning other revoked IDs.

• Example: The W3C Verifiable Credentials Status List 2021 specification defines a standardized, privacy-preserving status list encoded as a bitstring.

This pattern issues a special Status List Verifiable Credential (VC) that contains a bitstring where each bit represents the status (revoked/active) of a corresponding credential. The holder presents both their main credential and a cryptographic proof derived from the status list VC.

• Key Benefit: Enables batch status checks and reduces the need for individual on-chain transactions per credential.
• Implementation: Used in frameworks like Trinsic's ecosystem and compliant with W3C standards.

A lightweight smart contract on-chain acts as an immutable pointer or anchor to the off-chain revocation data. The contract stores only a cryptographic commitment (like a Merkle root) or a URL to the current revocation list.

• Process: 1) Issuer updates the off-chain list. 2) Issuer publishes the new commitment to the smart contract. 3) Verifiers check the credential's proof against the committed root.
• Example: Ethereum Attestation Service (EAS) schemas can be configured to reference off-chain revocation registries.

Dedicated credential status services (CSS) are hosted, high-availability endpoints that provide real-time revocation status. They offer APIs for issuers to update status and for verifiers to query it, often using signed JSON Web Tokens (JWTs) or similar tokens to attest to status.

• Advantage: Enables instant revocation and complex status logic (e.g., suspended, expired).
• Real-World Use: Employed by enterprise Digital Identity platforms and IoT credential management systems.

Cryptographic accumulators (like RSA or bilinear map accumulators) allow an issuer to aggregate all valid credential identifiers into a single, constant-size value. To revoke a credential, the issuer updates the accumulator and provides witness updates to non-revoked holders.

• Privacy: The accumulator itself reveals no information about the set of valid credentials.
• Challenge: Requires a mechanism for efficient witness updates to holders, often via a witness update service.

While not revocation itself, expiration timestamps are a critical complementary mechanism. A credential with a passed expiration is considered invalid, reducing the active window where revocation checks are necessary. This is often combined with off-chain revocation for suspension before natural expiry.

• Standard Field: The expirationDate property in a W3C Verifiable Credential.
• System Design: Short-lived credentials minimize reliance on persistent revocation lists.

Off-chain revocation depends on a revocation registry, a trusted data source (often a centralized server or a decentralized network) that maintains the current revocation status. This creates a trust anchor. The security of the entire system hinges on the availability, integrity, and correct operation of this registry. If the registry is compromised or goes offline, verifiers cannot check credential status, breaking the verification process.

A core challenge is ensuring status freshness—the guarantee that a verifier sees the most recent revocation state. Updates to the off-chain registry are not atomic with on-chain state. This creates a time-of-check vs. time-of-use vulnerability. An issuer could revoke a credential after a verifier checks the registry but before the credential is used, leading to acceptance of a revoked credential. Systems use mechanisms like sliding window nonces or timestamped accumulators to mitigate this risk.

Querying an off-chain registry can leak metadata. A simple request for a credential's status reveals to the registry operator that a specific credential ID is being verified, potentially linking the holder's activity. Advanced schemes like private information retrieval (PIR) or zero-knowledge proofs of non-revocation (e.g., BBS+ signatures with revocation accumulators) allow a verifier to check that a credential is not on a revocation list without revealing which credential they are checking.

The issuer retains ultimate control. They must securely manage the revocation authority private key used to sign updates to the revocation registry. Loss or compromise of this key can allow an attacker to illegitimately revoke any credential or, worse, make the revocation registry unusable. This centralizes a critical security function, contrasting with the decentralized ideals of many blockchain systems.

Shifting revocation off-chain adds operational overhead for verifiers. They must:

• Integrate with external APIs or services to fetch status proofs.
• Perform additional cryptographic computations to verify status proofs (e.g., accumulator witness verification).
• Manage potential API rate limits and costs associated with the registry service. This complexity can be a barrier to adoption and introduces new points of failure in the verification pipeline.

A lack of universal standards for off-chain revocation mechanisms can lead to fragmentation. Different issuers may use incompatible registry designs (e.g., revocation lists vs. accumulators), status proof formats, or API interfaces. This forces verifiers to support multiple, complex integration paths, reducing system robustness and increasing the attack surface. Efforts like the W3C Verifiable Credentials Data Model aim to define standard status check methods.