Queries Regarding Status List v2021 W3C Specification


I have few questions related to `StatusList2021Entry` and 
`StatusList2021Credential`, and I would like to first present a scenario 
of credential issuance based on my understanding of the Specification's 
Public Draft, as this will help me in explaining my queries better.

- When an issuer (did:issuer) issues a Verifiable Credential (say 
`VC-1`) to holder (did:subject), it attaches `credentialStatus` 
attribute in that Verifiable Credential (VC-1). VC-1 would look 
something like following:


   "@context": [
   "id": "VC-1",
   "type": ["VerifiableCredential"],
   "issuer": "did:issuer",
   "issued": "2021-04-05T14:27:42Z",
   "credentialStatus": {
     "type": "StatusList2021Entry",
     "statusPurpose": "suspension",
     "statusListIndex": "0",
   "credentialSubject": {
     "id": "did:subject",
     "type": "Person"
   proof: { ... }
In the above VC-1:
   - Focusing on the `credentialStatus` attribute:
      - `statusListIndex`: A postion reserved for tracking VC-1's status
      - `statusListCredential`: An URL which points towards the location 
of the `StatusList2021Credential` VC document
      - `id`: The id of credentialStatus which is formed by concatenating 
`statusListCredential` and `statusListIndex`

- After VC-1 is issued to the holder, a new Verifiable Credential 
document is also issued of type `StatusList2021Credential`. Let name it 
VC-SL. Here's what it would look like:


   "@context": [
   "id": "https://<VDR-API-URL>/<recovation-registry-endpoint>/<id-1>",
   "type": ["VerifiableCredential", "StatusList2021Credential"],
   "issuer": "did:issuer",
   "issued": "2021-04-05T14:27:40Z",
   "credentialSubject": {
     "type": "StatusList2021",
     "statusPurpose": "suspension",
   "proof": { ... }

Following are my queries:

1. The specification mentions about two primary statuses: `revocation` 
and `suspension`, both of them indicates the VC being unusable. Now, if 
I am trying to issue a credential, it won't make sense to attach 
credentialStatus having either `revocation` or `suspension` in the VC 
document. In this situation, if we want to track the status of the 
document, do we only attach the `credentialStatus` attribute only when 
we want to render the VC unusable? If no, then should `statusPurpose` 
attribute carry some string value other than `revocation` or 
`suspension` which would imply that the credential is active?

2. In the first paragraph of [Conceptual 
it is mentioned that a credential isn't revoked if the value of a bit is 
0, else 1. As there are two primary statuses "revocation" and 
"suspension", does the value 0 implies "suspension"? If yes, then in 
implementations where there are more than two statuses, does the value 0 
represents all those values, except "revocation"?

3. How an update of `credentialStatus` would be like? In above VC 
Document (VC-1), attribute `statusPurpose` is "suspension". If the VC 
document's status has to change from "suspension" to "revocation", apart 
with the  change in "statusIndex" bit in `StatusList2021Credential` 
document (VC-SL) at index "0" from `0` to `1`, would there also be an 
in-place update of `VC-1` document, where the `statusPurpose` attribute 
value changes from "suspension" to "revocation"?

4. Since, the `credentialSubject` property of VC-SL doesn't carry any 
sensetive PII, can it be stored on a VDR, for e.g., in a Public 
Blockchain as part of its Revocation Registry?

5. The `statusPurpose` property of `credentialStatus` present in the 
`StatusList2021Entry` (VC-1) tells us about the status of the credential 
its located in. I am not able to understand the role of `statusPurpose` 
of VC-SL. The VC-SL document has a list of bits, each indicating a 
status of one Verifiable Credential, so why would need to know about 
status of bitstring?

Arnab Ghose
Blockchain Engineer
Website: https://hypermine.co

Received on Wednesday, 27 September 2023 08:04:58 UTC