StatusList2021

The core innovation is encoding statuses as a bitstring, where each bit represents the status (e.g., 0 for valid, 1 for revoked) of a single credential. This creates an extremely compact data structure. For example, the status of 10,000 credentials can be stored in just over 1.2KB of data. The bitstring is then encoded as a base64url string for inclusion in a credential's credentialStatus property.

The StatusList is itself issued as a Verifiable Credential (a StatusList2021Credential). This means its integrity and issuer can be cryptographically verified, just like any other VC. It can be hosted anywhere—on a traditional web server, a decentralized storage network like IPFS, or a personal data store—without requiring a centralized, permissioned revocation registry.

To check a credential's status, a verifier reads the credentialStatus field, which contains two critical pieces of information:

• statusListIndex: The integer position (index) of this credential's status within the bitstring.
• statusListCredential: The URI where the StatusList2021 Credential itself can be fetched. The verifier retrieves the list, decodes the base64url to a bitstring, and checks the bit at the specified index.

The standard defines a statusPurpose field to distinguish between different types of statuses, preventing ambiguity. The two primary purposes are:

• revocation: Indicates the credential has been revoked by the issuer.
• suspension: Indicates the credential is temporarily inactive. This allows a single credential to have multiple independent status lists (e.g., one for revocation, another for suspension) tracked separately.

StatusList2021 enhances privacy compared to traditional revocation methods:

• Unlinkable Checks: Querying a status list reveals only an index number, not the credential identifier itself.
• Batch Updates: Issuers update the status of many credentials by publishing a single new bitstring, making it difficult to correlate updates with specific individuals.
• No Direct Query: The verifier fetches the entire list once and can check any index locally, rather than querying a central service for each credential.

StatusList2021 is the successor to the draft BitstringStatusList specification. Key evolutions include:

• Formal standardization as a W3C specification.
• The status list is now a full Verifiable Credential with its own metadata, not a plain bitstring.
• Introduction of the statusPurpose field for clearer semantics.
• Defined JWT and SD-JWT representations for the status list credential itself.

Beyond permanent revocation, StatusList2021 can manage temporary states. For example:

• Suspending a driver's license during an investigation.
• Pausing access credentials for an employee on leave.
• Placing a hold on a membership credential. The status can be toggled back to 'valid' by updating the bitstring, providing a flexible mechanism for non-permanent status changes without re-issuing the credential.

The standard is extensible for custom statuses defined by the issuer. The statusPurpose property in the credential can specify types beyond the predefined revocation or suspension. Examples include:

• expiration: For managing rolling expirations.
• endorsement: To indicate a credential has received a secondary approval.
• accreditation: For tracking the status of an accrediting body's approval. This allows issuers to model complex real-world status workflows.

StatusList2021 is often used with Decentralized Identifiers (DIDs) and blockchain-based registries. The status list credential itself is a Verifiable Credential, signed by the issuer and its statusListCredential property points to a resolvable URI (e.g., on IPFS or a blockchain). This creates a tamper-evident, decentralized status mechanism that doesn't rely on a single centralized database, aligning with Web3 principles.

The bitstring compression is critical for scalability. A single StatusList2021 credential can encode the status of tens of thousands of individual credentials in a few kilobytes. This makes it practical for large-scale deployments like:

• University degree revocation lists.
• Professional license status for millions of practitioners.
• IoT device certificates in massive networks. Efficiency in storage and bandwidth is a key advantage over traditional list-based approaches.

When combined with BBS+ signatures or other zero-knowledge proofs, StatusList2021 enables privacy-preserving status checks. A holder can prove their credential's status bit is '0' (valid) without revealing the credential's index in the list or any other identifying information. This prevents correlation and tracking by verifiers, a significant advancement for privacy in verifiable credential ecosystems.

StatusList2021 uses a bitstring where each bit represents the status (e.g., 0=valid, 1=revoked) of a single credential. This list is then GZIP-compressed and Base64-encoded into a compact statusListCredential. This compression is critical for efficiency, as storing a full list of individual revocation entries on-chain or in a registry would be prohibitively expensive and slow.

A core privacy feature is that a verifier only learns the status of the specific credential index being checked. The verifier fetches the entire compressed list but only decrypts and checks the single relevant bit. This prevents the verifier from learning about the status of any other credentials referenced in the same list, supporting unlinkability across different presentations.

Each Verifiable Credential must have a unique statusListIndex (an integer) that points to its specific bit in the list. The security of the entire scheme depends on the cryptographic binding between the credential's identifier and this index. If an issuer can reassign indices arbitrarily, they could potentially bypass revocation. The statusListCredential itself is a signed Verifiable Credential, ensuring the list's integrity and provenance.

The issuer maintains the statusListCredential, typically hosted at a URI specified in the credential. This creates a liveness dependency on the issuer's server. If the server is offline, statuses cannot be checked. While decentralized storage (e.g., IPFS, blockchain) can mitigate this, it introduces other trade-offs like update latency and cost. The issuer's ability to update the list is also a central point of control.

The standard defines a statusPurpose property (e.g., revocation or suspension) to clarify the meaning of the bits. This prevents ambiguity. A security consideration is ensuring all parties (issuer, holder, verifier) agree on the semantics. For example, a '1' bit must consistently mean 'revoked' across the ecosystem for that specific list purpose to avoid security-critical misinterpretations.

Verifiers are expected to cache the status list to reduce load on the issuer and improve performance. However, this introduces a freshness problem. Stale caches could lead to accepting revoked credentials. The specification recommends using HTTP caching headers (Cache-Control, Expires) but the ultimate responsibility for obtaining a sufficiently fresh list lies with the verifier, creating a potential security gap if not implemented correctly.

The core data structure of StatusList2021: a compressed bitstring where each bit represents the status of a single credential. A bit value of 1 typically indicates a credential is revoked or suspended.

• Efficiency: A single list can manage status for up to 16,384 credentials.
• Storage: The bitstring is encoded as a Base64 GZIP-compressed string (statusListCredential.credentialSubject.encodedList).

The specific Verifiable Credential that contains the status list bitstring itself. It is issued by the same entity that issues the VCs it governs and is publicly accessible via a URL.

• Structure: Contains the encodedList in its credentialSubject.
• Purpose: Distinguished by its credentialSchema pointing to the StatusList2021 JSON schema.

A required integer property in a Verifiable Credential that uses StatusList2021. It specifies the precise bit position within the status list bitstring that corresponds to that credential's status.

• Function: Acts as a pointer, enabling privacy-preserving checks. The verifier learns only the status of that specific index.
• Range: Valid values are from 0 to 131,071, though practical list sizes are smaller.