Credential Status VCs
This page outlines a technical reference for how credential status is structured and signed as a Verifiable Credential, so verifiers can determine whether a credential remains valid.
The page defines the Verifiable Credential format that EBSI supports for conveying credential status information:
| Credential Status VC type | Description | Legal Entity VCs | Natural Person VCs |
|---|---|---|---|
| Bitstring Status List v1.0 | Verifiable Credential containing information about a batch of VCs. Ref: https://www.w3.org/TR/2025/REC-vc-bitstring-status-list-20250515/ | ✓ | ✓* |
* The format does not allow to time-constrain the visibility of the status information.
The page will specify the format's default profile, how a status list is initialised, how a credential is revoked or suspended, and the respective responsibilities of issuers and verifiers.
Status List
The Status List consists of a bitstring, or flat array, associating each VC with an index. Each index has a binary value that signifies the status of the corresponding credential, where 0 indicates "valid," and 1 indicates "revoked" or "suspended". The purpose of the status list determines the specific process for revoking or suspending a credential. The Status List format has the following properties:
- A list contains information about a single state, e.g., revocation or suspension states.
- Revocation/Suspension metadata (date, reason) per VC are not supported.
- Status List metadata are supported.
- Update and grace periods are supported. Status lists can be updated: periodically or after every status change.
- Status List is a Verifiable Credential e-signed or e-sealed by the Issuer.
Default profile
This section defines a profile for the W3C Bitstring Status List (W3C Recommendation, May 2025).
| Attribute | Value |
|---|---|
| Status List size* | 131072 elements (16 KB) |
| Encoding | First GZIP-compressed, then base64 encoded values of a bitstring |
* This defines the minimal size of the Status List.
Initialisation of a new Status List
An empty bitstring list should be generated before any indexes are assigned to VCs. This ensures that all credentials are valid upon issuance and will contain a status list that is downloadable by proxy. If VCs need to support both suspension and revocation, VC statuses should be tracked in separate status lists.
While it is not necessary to have a fully populated index list, omitting high amounts will have a greater impact on the effectiveness of herd privacy. It is highly recommended that the status indices be set at random and should be unique. It is also advised not to use the same status unless it has a clear advantage over unique revocation indexes. The pattern or style chosen for the index should ensure maximum usage of the indexes, and randomness is preferred over sequential progress.
Furthermore, credential issuers should avoid creating a status list that groups credentials based on attributes such as gender, age or the credential Holder. For instance, segregating all credentials issued to women into Status List #1-500 and all men into Status List #501-1000. Anyone with access to this information could potentially infer the gender of an individual just by knowing which list their VC is on, undermining herd privacy.
Revoking/Suspending a VC
The revocation or suspension of a VC is achieved by changing the binary value of the bitstring at its given position in the bitstring. Every time the bitstring state changes, it must be compressed, encoded, and published as a Status VC of type BitstringStatusListEntry. It is encouraged to batch the revoked actions into issuer-defined batches, as the actual process can get heavy and may result in lagging during mass revocations. In cases where revocation actions are batched, the revocation process is lengthy, or when there could be a delay between the receipt and effective dissemination of the revocation status, the Issuer is responsible for informing a grace period. This grace period can be communicated in the revocation service statement or within the VC issuance policies. The Issuer must also define the revocation/suspension policies and strategies.
Verifier responsibilities
The Verifier decides whether to validate the status list or ignore it. Validation can be started by downloading the latest BitstringStatusListCredential by dereferencing the statusListCredential. It is encouraged to cache the results for a duration of time, depending on the severity of the revocations. The cache duration should also be in accordance with the Issuer's revocation/suspension policy and revocation batch update frequency (i.e., if the Issuer updates revocation within 24 hours, the status VC will have a lifetime of 24 hours). Status list issuance, validity and expiration dates must be checked, and invalid or expired Status Lists must not be processed. As the status list credential is a VC, it must be validated. Additionally, the credential under verification and status list credential must have the same Issuer. Actual verification of the status happens by decoding and decompressing the signed data, which yields a bitstring that can be looked up with an index to assert the validity of the VC.