Re: Queries Regarding Status List v2021 W3C Specification

Inline:

On Fri, Sep 29, 2023 at 2:04 AM Arnab Ghose <arnab@hypermine.in> wrote:

> 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?
>
yes, in the credential with multiple statuses you would see this:

https://w3c.github.io/vc-status-list-2021/#example-example-statuslistcredential


> 2. Before issuing a general VC, how does an issuer know about what the
> value for `statusListIndex` should be?
>
Implementation detail, but probably the issuer uses a counter and bitmap
primitives at minimum.

> Does it involve querying the source where the StatusList Credential is
> stored (say, a public Blockchain)?
>
Maybe, but I'd avoid blockchains if you can.

> If yes, then how could we be sure that a particular Index of encodedList
> isn't already occupied by some other VC?
>
Yes, the issuer is responsible for managing collisions... but there might
be use cases where a whole batch of credentials all use the same index...
It's the issuer's job to manage this stuff, and to avoid designing systems
that can be used to track the holder.


> Does the responsibility of keeping track of which VC is assigned to which
> statusIndex in the StatusList is left with the issuer?
>
Yes, the issuer is responsible for 100% of the claims that it signs... this
includes claims about credential status.


> 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>
>
>
> --
> Regards,
> Arnab Ghose
> Blockchain Engineer
> Hypermine
> Website: https://hypermine.co
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>