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/vc-status-list/ | ✓ | ✓* |
| 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 8.1.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 are 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.
Certificate Revocation List as Plain
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.
Initialization 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.
Initialization 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:
- Create a new VC with status id: s_id
- Create a secret seed
- Compute the revocation entry as valid = H(token, s_id) and add it to the Dynamic SL
- Publish the Dynamic SL as Credential Status VC via the Credential Status API
- Share the VC and the Credential Status Secret VC with the Holder.
Revoking/Suspending a VC
Issuer revokes a VC at time t':
- Compute number of durations t' as defined in the table above
- Compute time-based password token
- Compute valid_hash hash corresponding validity
- Compute void_hash hash corresponding revocation/suspension
- Remove valid_hash from the Dynamic SL
- 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:
- Holder shares the VC under question, and CredentialStatusToken is used to prove revocation status.
- Verifier computes valid_hash and void_hash.
- 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.