Vocabulary definitions

[iherman]

(This issue is spawn from #69 (comment); it was deemed preferable to have it as a separate issue.)

This document yields a number of terms that must be incorporated into the credentials vocabulary at some point. I hope I am not mistaken with this list:

• Classes:
  • StatusListEntry
  • StatusListCredential
  • StatusList
• Properties:
  • statusPurpose
    • range: xsd:string
    • domain: StatusListEntry or StatusList
  • statusListIndex
    • range: xsd:string
    • domain: StatusListEntry
  • statusListCredential
    • range: StatusListCredential
    • domain: StatusListEntry
  • encodedList
    • range: xsd:string
    • domain: StatusList

I presume that these terms will be formally defined by this specification (which is perfectly fine from my point of view). However, to anticipate this (following w3c/vc-data-model#1209) there should be clear anchors that provide the referencable URLs for the vocabulary entry into this document. At the moment, there is a URL forStatusListEntry and StatusListCredentials, but all the others are missing. It may be as simple as providing an @id attribute on the table cell elements for the properties, but this will miss the reference for StatusList (which is "hidden" in the table row for credentialSubject.type).

[iherman]

(Copying the answer of @msporny from #69 (comment) for an easier discussion.)

@msporny:

We should probably have a different vocabulary for credential status. It's not required, but it might be the best way to structure things (separation of vocabulary purposes... where the credential vocabulary is for core VCDM things... and extensions get their own vocabularies)? Note that we will need to produce a separate JSON-LD context for status list because of people wanting to pull it into V1 VCs or other software systems (possibly).

[iherman]

@msporny

We should probably have a different vocabulary for credential status. It's not required, but it might be the best way to structure things (separation of vocabulary purposes... where the credential vocabulary is for core VCDM things... and extensions get their own vocabularies)?

I am a little bit worried to have too many mini-vocabularies that might become a maintenance nightmare. Should we also separate each cyryptosuite, in the case they add terms, into their own vocabulary? The same for JSON Schemas?

I am not worried if the credential vocab covers different areas. It is the same family of specs anyway...

[msporny]

I am a little bit worried to have too many mini-vocabularies that might become a maintenance nightmare.

Yes, it's a balancing act. I'm not entirely convinced on either direction. There are different maintenance issues either way. If we have one giant vocabulary, we have to coordinate a lot there. If we have mini-vocabularies, we have to manage all of them. Mini-vocabularies allow more independence and allow us to distribute the workload to other editors. One giant vocabulary is easier to maintain. The question becomes, who are we optimizing for here?

Should we also separate each cyryptosuite, in the case they add terms, into their own vocabulary?

At present, the DataIntegrityProof-based cryptosuites don't need a separate vocabulary... For the security vocabulary, it seems as if we've made the decision to have one giant vocabulary. So, maybe we should just follow the same pattern for all VCWG items?

The same for JSON Schemas?

Again, possibly... We have to be sure that we're ready for things to be almost fully formed before they come into the WG... it sounds like the WG is increasingly raising the bar for incubation/deployment before accepting work items in the future... and if that's the case, the work items might come in as separate vocabularies where we can't merge them into the main vocabulary?

It would also be helpful for developers to have one place to look, which is an argument to put everything into the core vocabulary.

I am not worried if the credential vocab covers different areas. It is the same family of specs anyway...

Yes, that's an argument for putting most everything into the credential vocab.

[iherman]

The issue was discussed in a meeting on 2023-09-15

• no resolutions were taken

View the transcript

1.10. Vocabulary definitions (issue vc-status-list-2021#81)

See github issue vc-status-list-2021#81.

Ivan Herman: there are a number of properties that are defined in the standard and are used from within JSON-LD, they must be added to a vocabulary....
… we need the range, domain, etc.

Kristina Yasuda: that problem goes away if the status list credential is not a vcdm :P.

Manu Sporny: two options: put in the VC vocabulary ... exists and is there ... another option is to create a different vocabulary doc ... for the status list spec ...
… and put it in that.
… on the fence on what to do ...
… the second approach seems cleaner ... but more pain ,.... vs just putting in the VC vocab easier to do.

Brent Zundel: anyone opposed to the VC vocab?

Ivan Herman: the credential vocab is already a collection in a sense.
… not to the VC DM only.
… so putting into that vocabulary is "clean enough".
… not devoted into any of the two options.

Joe Andrieu: just wanted to note that it is a VC and we support VCs over JWTs ...

Brent Zundel: manu and ivan seem to be on the same page ...

Manu Sporny: ivan, what would you prefer?

Brent Zundel: the point is that that's a conversation beteween the two of you.

Ivan Herman: inclined to put in the VC vocab.

[iherman]

Isn't this a duplicate of #17 (although it seems to give more details of the possible statements)? If so, this could be closed right away in favour of #17, or marked as to-be-closed in the case #105 get merged.

Cc @msporny

[msporny]

Yes, this is a duplicate of #17, closing.