StatusListCredential

A university issues a Verifiable Credential for a graduate's degree. If the degree is later revoked due to academic misconduct, the issuer updates a single StatusListCredential to set the corresponding bit from 0 to 1. Verifiers (like employers) check this status list to instantly confirm the diploma's validity without contacting the university directly, enabling privacy-preserving and scalable revocation.

A medical board issues licenses as Verifiable Credentials to practitioners. If a doctor's license is temporarily suspended, the board flips the relevant bit in its Status List. Hospitals and insurance providers can programmatically check this status during credential verification, ensuring only currently licensed professionals can access systems or file claims, automating compliance.

In a manufacturing supply chain, a Verifiable Credential grants a supplier access to a secure logistics portal. If the supplier's contract is terminated, the manufacturer revokes the access credential by updating the StatusListCredential. This instantly disables portal access across all systems that check the status, providing a cryptographically secure and auditable method for managing dynamic permissions.

An event organizer issues NFT-based tickets as Verifiable Credentials. If a ticket is reported stolen or fraudulent, the organizer can revoke it by updating the central StatusListCredential. Scanners at the venue gate check the status list in real-time, preventing the invalidated ticket from being used. This provides a decentralized and efficient alternative to traditional centralized blacklists.

A bank issues a KYC Credential after customer onboarding. If the customer's risk profile changes (e.g., sanctions list addition), the bank can suspend the credential via a StatusListCredential. Other financial institutions in the network can trust this status during transactions, enabling interoperable compliance without sharing sensitive customer data, reducing friction in decentralized finance (DeFi).

A corporation issues employee access badges as Verifiable Credentials. Upon an employee's departure, HR updates the StatusListCredential to revoke the badge credential. Physical access control systems and internal software (like HR portals) that verify the credential will immediately deny access. This creates a unified, cryptographically verifiable offboarding process across digital and physical systems.

A core privacy feature is the ability to prove a single credential's status without revealing the entire list. Using cryptographic accumulators or bitstring proofs, a verifier can request proof that a specific index (e.g., bit position 42) is set to 0 (valid) or 1 (revoked) without learning the status of any other credentials on the list. This prevents correlation across different verifications.

Security depends on the cryptographic binding between the StatusListCredential and the credentials it governs. The status list index for a credential must be immutably linked (e.g., embedded in the credential's credentialStatus field). Tampering with this link or forging the StatusListCredential itself must be prevented by the issuer's digital signature (e.g., EdDSA, ES256K) on the Verifiable Credential.

Verifiers must check the issuanceDate and potential expirationDate of the StatusListCredential to ensure the status information is fresh. Relying on a stale list is a critical security failure. Furthermore, the status list must be hosted at a highly available, tamper-evident endpoint (often a decentralized storage like IPFS or a public HTTPs endpoint) to prevent denial-of-service attacks that block revocation checks.

Even with selective disclosure, the status list index itself can be a correlatable identifier. If a user presents the same index to multiple verifiers, those verifiers can collude to track the user. Mitigations include using privacy-preserving identifiers (like salted hashes) for the index or allowing users to obtain dynamic, one-time indices from the issuer for each presentation.

The issuer maintains ultimate control over the status list, creating a central point of control for revocation. This is a security and availability dependency. Malicious or compromised issuers can falsely revoke valid credentials or fail to revoke compromised ones. Decentralized status registries or smart contract-based lists are emerging patterns to distribute this trust.

The long-lived nature of credentials requires cryptographic agility. The digital signature scheme (e.g., Ed25519, secp256k1) used to sign the StatusListCredential must be considered secure for the entire potential lifespan of the credentials it manages. Issuers must have a migration path to rotate keys or upgrade algorithms without breaking existing credential status checks.

The core data structure referenced by a StatusListCredential. It's a compact bitstring where each bit represents the status (e.g., revoked or valid) of a corresponding Verifiable Credential.

• Efficiency: A single StatusListCredential can manage the revocation status of thousands of individual VCs.
• Indexing: Each VC contains a statusListIndex that points to its specific bit position in the list.
• Privacy: The bitstring itself reveals no information about the holders; it's just a sequence of 1s and 0s.

The method by which a holder presents one or more Verifiable Credentials to a verifier. A StatusListCredential may be presented alongside a credential to prove its current status.

• Selective Disclosure: Holders can choose which claims from their VCs to reveal.
• Proof of Control: Demonstrates the holder possesses the private keys for the credentials.
• Status Proof: The verifier checks the relevant bit in the presented StatusListCredential to confirm the primary credential is not revoked.

The two primary statuses managed by a StatusListCredential, encoded in its bitstring.

• Revocation (bit=1): A permanent invalidation of a credential. Used when the credential should never be valid again (e.g., a diploma is rescinded).
• Suspension (bit=1): A temporary invalidation of a credential. The credential can be reinstated by flipping the bit back to 0 (e.g., a membership put on hold).

The semantic meaning of the bit value is defined by the statusPurpose property in the StatusListCredential.