Re: Queries Regarding Status List v2021 W3C Specification

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

<https://transmute.industries>