Re: VC Bitstring Status List

Hi, Manu!

Thank you for your answers. Please see some follow-up questions below in blue.

Best,
Stefannie

________________________________
From: Manu Sporny <msporny@digitalbazaar.com>
Sent: Tuesday, February 20, 2024 11:17 PM
To: ステファニー タン（SBIホールディングス） <tstefan@sbigroup.co.jp>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: Re: VC Bitstring Status List

On Tue, Feb 20, 2024 at 3:23 AM ステファニー タン（SBIホールディングス）
<tstefan@sbigroup.co.jp> wrote:
> Thank you to Manu and Dave from Digital Bazaar for this presentation! I forwarded the material to our technical team to get their thoughts.

The meeting and video presentation is in 3 hours. The video
presentation might be useful as well. That will be sent to the mailing
list soon after the meeting (this week).

> What does the semantics of the bit sequence mean: if it is 1, is it revoked, if it is 0, is it revoked, or if it is 0, is it not revoked?

The "statusPurpose" lets you know what the semantics of the bit are:

https://w3c.github.io/vc-bitstring-status-list/#bitstringstatuslistentry


For example, "revocation" means that the semantics of the bit is about
revocation. 1 means "revoked", 0 means "not revoked".


  *
We noticed that this is not written in such a way that conformance is recommended. (for example, "the status MUST be true when the bit is set(1) and false when unset (0). is there a reason for that?

There is also a "statusPurpose" of "message", which is used to convey
an arbitrary human-readable message related to the status of the
credential.


  *
We would appreciate it if there could be a concrete example for this coming in the future? I noted that there already seems to be a github PR with this concern. (https://github.com/w3c/vc-bitstring-status-list/issues/135 )

> Who guarantees that data cannot be created with a different ListIndex? (Is credentialStatus subject to VC signature?)

Yes, credentialStatus is protected by the VC signature. In fact, both
the VC and the status list VC is digitally signed by the issuer, so
only the issuer of each credential can change any of the information.
If someone else tries to change the information, the signature will
show that the information has been tampered with and verification will
fail.

> I think the gain is reducing the amount of information. When using a bit string and there is one data object, my understanding is that write cannot be executed concurrently. Is that correct? (Wouldn't this be a challenge, especially if you put a Data Registry on the blockchain?)

You can't write to the same bitstring concurrently, no, but remember
that you can have many parallel bitstrings, which you CAN write to
concurrently. Also note that you don't have to write to the status
list every time there is an update, it is expected that updates would
be batched and released once per day or once per week... in all of
those cases, the updates would effectively be concurrent (because the
issuer would batch up all the changes and write a new status list VC
once to whatever storage medium they're using -- website or blockchain
or something else).

> What do you think about the governance of the bit index (who can rewrite it)? Ideally, there would be a key pair when adding a single Bit string, and it would be organised in such a way that it cannot be rewritten without the key pair (private key). Is that understanding correct?

Yes, you can't publish or update the status list w/o the private key.
It is possible for others authorized parties to manage the bitstring
entry by using something like the VC API that allows you to change
status information as long as the authorized party is using an access
token or capability to provide access to the status changing service:

https://w3c-ccg.github.io/vc-api/#update-status


One way this has been implemented is that the issuer provides an
access token to change the status information associated with a
particular credential or set of credentials. The entity changing the
status information would then call the API above to flip the bits
accordingly. The issuer would then re-publish the list during the next
scheduled update cycle (once per day, once per week, etc.).

Does that answer all of your questions, Stefannie?

-- manu


  *   I understand the answer to (iii) and (iv) about the concurrent bitstring and updating the status list without the private key respectively, but in that case, am I correct in understanding that in order for the VC to be effective, the Issuer must have a reasonable level of availability? For example, if ttl is set to 3600 seconds, the Issuer's associated API is not allowed to have downtime longer than 3600 seconds (otherwise there would be no valid status list on the net), and this is an understanding that encompasses the issues faced by conventional CRL lists and OCSP. Am I correct?
  *   Relatedly, it was pointed out that there is a contradiction between ttl and validUntil, but that is only because there is a possibility of contradiction between validUntil and ttl in so-called short-lived VCs, and in that case it would be sufficient to specify that it is an And constraint. In that sense, I think StatusListCredential is a form of short-lived VC (i.e. each time the TTL expires, the Issuer continues to issue a new one), is this correct?

--
Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/