Independently of the strategy, the following VC status formats are supported:

Credential Status VC type	Description	Legal Entity VCs	Natural Person VCs
OneTimeStatus2023	Short-lived VC attesting the validity of another long-lived VC. Defined in this document. Applicable only to the Short VC lifetime strategy.	✓	✓
StatusList2021	Verifiable Credential containing information about a batch of VCs. Ref: https://www.w3.org/TR/2023/WD-vc-status-list-20230427/	✓	✓*
CRLBloomFilter2023	Verifiable Credential containing information about a batch of revoked / suspended VCs. Defined in this document.	✓	✓*
CRLPlain2023	Verifiable Credential containing information about a batch of VCs in a CRL format.	✓	✓*
DynamicSLBloomFilter2023	Verifiable Credential containing information about a batch of VCs. Defined in this document.	✓	✓

* The format does not allow to time-constrain the visibility of the status information.

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 Status List 2021 (version published on 27 April 2023).

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 StatusList2021Entry. 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 StatusList2021Credential 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 StatusList2021Credential is a VC, it must be validated. Additionally, the credential under verification and StatusList2021Credential 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.

Plain Certificate Revocation List

A Certificate Revocation List (CRL) is a simple list that marks revoked or suspended credentials. The plain version contains all revoked Verifiable Credentials identifiers with the date and reason for revocation.

Default profile

The content of the CRL is a map of objects, where the map identifier is the VC identifier, and the content is the date for revocation and the reason for it. The list size should not exceed 50 000 objects to keep the data sizes optimal.

Initialisation of new CRL

A fresh CRL is created with an empty map.

Revoking/Suspending a VC

A VC is revoked by creating an object containing a revocation date and an optional reason. The object is then added to the CRL map using the VC identifier as a map key.

Verifier responsibilities

The Verifier must always resolve the CRL from the Verifiable Credential status. The CRL map is used to look up if a Verifiable Credential identifier exists in the key. If the key exists, the VC has been revoked, and the Verifier may use the extra details (revocation date and reason) to determine if the credential was valid at a certain point.

Certificate Revocation List with Bloom Filter

A bloom filter is a space-efficient data structure that provides approximate answers to queries about a large dataset. The CRL implements a bloom filter for membership testing to verify whether the associated verifiable credential is in the list.

Default profile

This section defines a default profile for a Bloom Filter-based CRL. The profile is compatible with the EUDCC DGC Bloom Filter.

Attribute	Value	Description
Version	1	A number that describes the current version of the used Data Format.
Used Hashing	0	A number of the used Hash algorithm (TOB) or Hash Strategy. Default
k	27	Amount of used Hash function calculations
p	1e-8	Probability Rate. Default: 1 in 99 857 727
n	1e5	Amount of Elements for which the filter was constructed. Default 100 000
Data model and encoding		See https://github.com/eu-digital-green-certificates/dgc-bloomfilter

The Bloom Filter CRL has the following properties:

• The CRL holds information about a single state, e.g., revocation or suspension state.
• Revocation/Suspension metadata (date, reason) per VC are not supported.
• CRL metadata are supported.
• Update and grace periods are supported. CRL can be updated: periodically or after every status change.
• CRL is a Verifiable Credential e-signed or e-sealed by the Issuer.
• This format has been tested and used at scale in the EU.

Initialisation of a new CRL

A new CRL is an empty Bloom Filter initialised with the default parameters unless other parameters are defined by the domain or use case.

Revoking/Suspending a VC

To revoke or suspend a VC, the unique VC revocation ID (value of vc.credentialStatus.index) is added to the Bloom Filter. When a verifier receives a VC, it computes the ID and checks whether the VC is a member of the CRL, in which case it is revoked. Once Verifiers have a VC, they can check the VC status anytime without contacting or notifying the Holder. This is possible since the revocation ID used to generate the Bloom filter is static. Suspension and revocation information must be managed in separate Bloom Filters.

Verifier Responsibilities

The Verifier decides whether to validate the status list or ignore it. Validation can be started by downloading the latest CRL by dereferencing the vc.credentialStatus.statusListCredential. It is encouraged to cache the results temporarily, with the duration depending on the criticality of the revocations and consistent with the grace period specified by the Issuer's issuance policies. As the CRL is a VC, it must be validated. Additionally, the credential under verification and CRL must have the same Issuer. Actual verification of the status happens by decoding and decompressing the signed data, which yields a bloom filter that can be searched using the revocation ID of the VC.

Dynamic Status List

Dynamic SL is a variant of the CRL where the entries are periodically updated. The Issuer will deterministically compute the time-dependent token, re-populate the CRL and publish it as a Credential Status VC. Only the Issuer and the Holder know the time sequence of tokens for the VC; hence the Verifier can check the VC status only within the time window for which the token, shared by the Holder, is valid. When an issuer issues a VC, it also provides the Holder with a unique seed issued as an additional Credential Status Secret VC. Once the Holder shares a VC with a verifier, they also derive a token and share it by issuing a Credential Status Token VC, which the Verifier can then use to check the status of the VC in question. After the token expires, the Issuer updates the Dynamic SL so that the Verifier can no longer check the status of the VC from previous or updated Dynamic SLs. This property is important to protect the privacy of the Holder.

Default profile

The Dynamic Status List uses bloom filters as storage, thus sharing the same default profile as CRL.

Initialisation of a new Dynamic SL

A new Dynamic SL is initialised the same way as a CRL. It is an empty Bloom Filter generated with the default parameters unless other parameters are defined by the domain or use cases.

Issuing a VC with dynamic revocation

The Issuer must issue a Shared Secret VC to the Holder. See the data model section for the data model and schemas. The following attributes are used to define the processes:

Attribute	Description
H(x), H(x, y)	Hashing function. SHA-256 MUST be used. Multiple inputs are simply concatenated.
HMAC(x, y)	Hash-based message authentication code function HMAC-SHA256 MUST be used.
s_id	Status ID defined by the credentialStatus.index. The value must be decoded before use.
seed	A secret used to compute the time-based password. This value is delivered as a second VC.
t'	Count of the number of durations, where duration is chosen by use case, and t-now is a unix epoch value representing the current time. Formula: floor(t-now / duration)
token	Time-based password Formula: HMAC(seed, t’)
valid_hash	Status hash to declare validity Formula: H(token, s_id)
void_hash	Status hash to declare revocation or suspension Formula: H(valid_hash)

Issuer issues a new VC at time t:

1. Create a new VC with status ID: s_id
2. Create a secret seed
3. Compute the revocation entry as valid = H(token, s_id) and add it to the Dynamic SL
4. Publish the Dynamic SL as Credential Status VC via the Credential Status API
5. Share the VC and the Credential Status Secret VC with the Holder.

Revoking/Suspending a VC

Issuer revokes a VC at time t':

1. Compute the number of durations t' as defined in the table above
2. Compute time-based password token
3. Compute valid_hash hash corresponding validity
4. Compute void_hash hash corresponding revocation/suspension
5. Remove valid_hash from the Dynamic SL
6. Add void_hash into the Dynamic SL

Updating the Dynamic SL periodically

The Issuer updates the SL periodically. At every period of t, re-compute all values with VC's status, either valid_hash or void_hash.

Holder responsibilities

The Holder must issue a CredentialStatusToken VC to reveal the time-based password token valid when the VC is shared. The Verifiable Presentation time of issuance must match the value of t-now used for the token and the issuance time of the CredentialStatusToken.

Verifier responsibilities

The Verifier decides whether to validate the status list or ignore it. Validation can be started by downloading the latest SL by dereferencing the vc.credentialStatus.statusListCredential. It is encouraged to cache the results for a reasonable time, depending on the criticality of the revocations. As the CredentialStatusToken is a VC, it must be validated. Actual verification of the status happens by decoding and decompressing the signed data, which yields a Bloom filter that can be searched using the revocation ID of the VC.

The following steps define the verification process:

1. Holder shares the VC under question, and CredentialStatusToken is used to prove revocation status.
2. Verifier computes valid_hash and void_hash.
3. The existence of valid_hash means that the credential is valid, while the existence of void_hash means that the credential is revoked/suspended. Any other results signify an error or an attack.