Re: Queries Regarding Status List v2021 W3C Specification

Hi Orie,

Thank you for your response to the queries. It made things a lot 
clearer. I just have two more queries to ask you regarding the 
specification:

1. I want to expand on your answer of the 5th question I asked in my 
previous email. Since there are two prime statuses: "revocation" and 
"suspension", and if a StatusList Credential specifies the kind of 
Status List (whether the list is for "revocation" or "suspension"), does 
that mean an issuer who wishes to keep two lists (for each status), they 
would need to issue two StatusList Credential for each status?

2. Before issuing a general VC, how does an issuer know about what the 
value for `statusListIndex` should be? Does it involve querying the 
source where the StatusList Credential is stored (say, a public 
Blockchain)? If yes, then how could we be sure that a particular Index 
of encodedList isn't already occupied by some other VC? Does the 
responsibility of keeping track of which VC is assigned to which 
statusIndex in the StatusList is left with the issuer?

> inline:
> 
> On Wed, Sep 27, 2023 at 3:06 AM Arnab Ghose <arnab@hypermine.in> wrote:
> 
>> Hi,
>> 
>> 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:
>> 
>> `VC-1`:
>> 
>> ```json
>> {
>> "@context": [
>> "https://www.w3.org/2018/credentials/v1",
>> "https://w3id.org/vc/status-list/2021/v1",
>> "https://json-ld.org/contexts/person.jsonld"
>> ],
>> "id": "VC-1",
>> "type": ["VerifiableCredential"],
>> "issuer": "did:issuer",
>> "issued": "2021-04-05T14:27:42Z",
>> "credentialStatus": {
>> "id": "https://<VDR-API-URL>/<recovation-registry-endpoint>/<id-1>#0",
>> "type": "StatusList2021Entry",
>> "statusPurpose": "suspension",
>> "statusListIndex": "0",
>> "statusListCredential": 
>> "https://<VDR-API-URL>/<recovation-registry-endpoint>/<id-1>"
>> },
>> "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:
> 
> Technically the status list comes first, it needs to be allocated 
> before a credential can be issued.
> 
>> `VC-SL`:
>> 
>> ```json
>> {
>> "@context": [
>> "https://www.w3.org/2018/credentials/v1",
>> "https://w3id.org/vc/status-list/2021/v1"
>> ],
>> "id": "https://<VDR-API-URL>/<recovation-registry-endpoint>/<id-1>",
>> "type": ["VerifiableCredential", "StatusList2021Credential"],
>> "issuer": "did:issuer",
>> "issued": "2021-04-05T14:27:40Z",
>> "credentialSubject": {
>> "id": 
>> "https://<VDR-API-URL>/<recovation-registry-endpoint>/<id-1>#list",
>> "type": "StatusList2021",
>> "statusPurpose": "suspension",
>> "encodedList": 
>> "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
>> },
>> "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?
> 
> For documents that have statuses that change, you attache each possible 
> status at the time of issuance, and after that point a verifier can 
> check the statuses, and the issuer can update them without 
> communicating to the holder.
> 
>> 2. In the first paragraph of [Conceptual 
>> Framework](https://www.w3.org/TR/vc-status-list/#conceptual-framework), 
>> 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"?
> 
> The working group is discussing enum statuses vs bit statuses... IMO 
> its not been going very well, and the only 2 statuses that are likely 
> to be reliable are suspension and 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"?
> 
> No update to the credential with the status is required. The status 
> list credential needs to update its bitstring every time a status for 
> one of the allocated credentials changes.
> 
>> 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?
> 
> Yes, people have already put Status List credentials in blockchains, 
> and the holder can also disclose them to verifiers who have no network 
> access.
> 
>> 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?
> 
> You want to make sure that status labels are not mixed, where a list 
> claims to be for revocation, but a credential claims that list is used 
> for suspension.
> 
>> --
>> Regards,
>> Arnab Ghose
>> Blockchain Engineer
>> Hypermine
>> Website: https://hypermine.co
> 
> --
> 
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
> 
> [1]

-- 
Regards,
Arnab Ghose
Blockchain Engineer
Hypermine
Website: https://hypermine.co

Links:
------
[1] https://transmute.industries