search

w3c / vc-bitstring-status-list

A privacy-preserving mechanism to publish status information for Verifiable Credentials.
https://w3c.github.io/vc-bitstring-status-list/
Other
22 stars 19 forks source link

Proposed improvement to the official vocabulary #158

Closed iherman closed 7 months ago

iherman commented 8 months ago

(I will be happy to produce a PR with these changes, but prefer to get some feedbacks first.)

Reading through the text, and comparing it with the current vocabulary, I would want to propose the following improvements to the latter, to make it as close as possible to the spec text:

  1. BitstringStatusListEntry is a subclass of cred:CredentialStatus.

    The cred vocabulary defines the credentialStatus property, whose range is cred:CredentialStatus; better make this statement here to clarify things.

  2. statusListCredential range is BitStringStatusListCredential.
  3. BitStringStatusListCredential is a subclass of cred:VerifiableCredential
  4. statusReference range is a URL (i.e., it is an ObjectProperty)
  5. statusSize range is xsd:positiveInteger
  6. The messaging part was also incorrect imho. The proper structure is:
    1. Introduce a (new) class, say, BitstringStatusMessage
    2. the range of statusMessage is BitstringStatusMessage
    3. the domain of status and message is BitstringStatusMessage

I was also wondering about the range of cs:statusListIndex which currently says it must be an integer encoded in a string based on 10. Why wouldn't a range xsd:nonNegativeInteger work here? Why this specific text in the spec?

I am also wondering whether it is worth adding a diagram for the vocabulary, just like we have for VC and DI. WDYT?

cc @dlongley

(Edited by adding the item no. 6 above)

iherman commented 8 months ago

Actually, I went ahead, and created a diagram, which helped me to have a better overview of the vocabulary. The results are in #159.

dlongley commented 8 months ago

I think all of the above suggested changes are correct. Similarly, I think we could probably use xsd:nonNegativeInteger for cs:statusListIndex to simplify. I also agree that we need a bit more for the messaging piece like you said (and agree with your proposal).

I do want to ensure that there's room for people to innovate and reuse terms like statusListCredential without needing to subclass BitstringStatusListCredential -- this doesn't prevent or discourage that, right?

iherman commented 8 months ago

I think all of the above suggested changes are correct. Similarly, I think we could probably use xsd:nonNegativeInteger for cs:statusListIndex to simplify.

In contrast to all other changes, this would require a change in the spec itself, though. Just saying...

I do want to ensure that there's room for people to innovate and reuse terms like statusListCredential without needing to subclass BitstringStatusListCredential -- this doesn't prevent or discourage that, right?

Hm. Setting the range for statusListCredential means that for any <K> in the following triple

<abcd> cs:statusListCredential <K> .

an inference engine would deduce a 

<K> rdf:type cs:BitStringStatusListCredential .

Ie, if you want to create a special category of credentials, it would be automatically yield a subclass of BitStringStatusListCredential. Is that a problem?

msporny commented 7 months ago

PR #159 has been merged. Can we close this now, @iherman? If so, please close.

dlongley commented 7 months ago

@iherman,

Ie, if you want to create a special category of credentials, it would be automatically yield a subclass of BitStringStatusListCredential. Is that a problem?

Unknown at this time -- I'm inclined to just let this go and not borrow trouble from the future.