- From: Orie Steele <orie@transmute.industries>
- Date: Fri, 29 Sep 2023 11:40:43 -0500
- To: Arnab Ghose <arnab@hypermine.in>
- Cc: public-credentials@w3.org, Vishwas Anand <vishwas@hypermine.in>
- Message-ID: <CAN8C-_LyRBydhApv+qVcJvtZLaCRrkjg=XGQsqQztTA3JfoV=Q@mail.gmail.com>
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>
Received on Friday, 29 September 2023 16:41:01 UTC