Meeting minutes
<ivan> Date: 2024-01-10
Manu: need to publish vc specs directory as a note
… make it so that any updates are automatically published
VCDM 2.0 Candidate Recommendation Proposal
<manu> The prepared CR-ready draft is here: https://
brentz: just 2 PRs marked before PR
<manu> and the corresponding vc-specs-dir is here: https://
Any changes to 1397 not merged should not affect the published CR technical content
selfissued: waiting for 1404 to be merged before resolving some PRs in JOSE-COSE
ivan: diagrams have been updated but waiting for comments from manu
manu: this looks fine
whilst 1404 is editorial selfissued's changes are not
TallTed: has issues with long media type
… image that says the media type has a typo
selfissued: one minus sign should change to a +
ivan: I cannot do it today sorry, can someone else?
TallTed: I will do a change suggestion on the PR
selfissued: either I or manu should merge it
manu: I will merge it
brentz: after 1397 is merged or closed we will begin the process of moving VCDMv2 to CR
manu: do we need to say that we can update this at any time?
<manu> DavidC: We said we're going to publish with a date, but then update, what do we do about the date?
ivan: publish wont happend before next Friday
… initial publication date will be 23 Jan 24
… once it is in the system the automatic publication process automatically updates the date
… its only the first version that we have to specify a date
<brentz> PROPOSAL: We will publish VC Specs Directories located at https://
<manu> +1
<dlongley> +1
<andres> +1
<pdl_asu> +1
<brentz> +1
<ivan> +1
+1
<cabernet> +1
<JoeAndrieu> +1
<TallTed> whoops
<bigbluehat> +1
<pauld_gs1> +1
<TallTed> +1
<Kevin-Dean-GS1> +1
RESOLUTION: We will publish VC Specs Directories located at https://
brentz: resoved unanimously
<TallTed> typo fix suggestions on 1404 -- https://
<selfissued> +1
<brentz> PROPOSAL: We will transition Verifiable Credentials Data Model v2.0 located at https://
<ivan> +1
<brentz> +1
<dlongley> +1
+1
<TallTed> +1
<manu> +1
<cabernet> +1
<pdl_asu> +1
<bigbluehat> +1
<pauld_gs1> +1
<andres> +1
<Kevin-Dean-GS1> +1
<selfissued> +1
RESOLUTION: We will transition Verifiable Credentials Data Model v2.0 located at https://
brentz: resolved unanimously
<ivan> https://
ivan: will manu update and cross check the approval request text with the URL I published
VC Spec Directories Volunteers
<manu> https://
manu: sent out a request for volunteers to maintain registeries and got 16 volunteers
… 5 are from the general community, rest are not
… are explaining work to volunteers to see if they are still interested
… we should be able to put 6 volunteers on each registry (DIDs and spec directory)
… I do not want to share the emails of the volunteer, but will share their linked in pages
… if anyone objects to anyone in this list they can notify the group
Bitstring Status List
<manu> PRs for Bitstring Status List -- https://
brentz: 20 PRs but majority are almost ready for merging
manu: the plan is to merge them all this weekend
w3c/vc-bitstring-status-list#100
manu: we had 3 status purpose values: revocation, suspension and status
… we have changed status to message
… we have pre-pended the word status to some of the property names
<manu> w3c/
w3c/vc-bitstring-status-list#110
manu: these affect existing implementations, but not technically difficult
… request to change base64 to base64url
… but there is no type for base64url yet
w3c/vc-bitstring-status-list#112
manu: request to retrieve historical status list
… so option to add date-time to the request
… some discussions about what to do if the issuer does not have the status list at the requested date-time
… nobody has implemented this feature yet, so should we fully specify this feature or wait for implementation experience
<manu> DavidC: We would like implementer feedback, but we shouldn't have a spec that has multiple options on the reply - that might be confusing to implementers. Select one option for the reply (when you don't have one, we should say you MUST/SHOULD return an error) vs. "it's up to implementers"
w3c/vc-bitstring-status-list#118
manu: we can make this change
… we should not mix and match the security mechanisms on the status list and the vcs that it contains
… they should all use the same mechanism e.g. JWT or data integrity
w3c/vc-bitstring-status-list#119
manu: adds an at risk marker to the bitstring format
… because there is parallel work in the IETF, so we might wish to align
<brentz> IETF work https://
w3c/vc-bitstring-status-list#121
manu: renames herd privacy to group privacy
w3c/vc-bitstring-status-list#123
manu: adding an at risk marker to the multiple status list feature
<cabernet> I believe we intend to implement it
manu: if there are insufficient implementors of this feature it will be removed
… we will need a test suite for it as well as implementations
w3c/vc-bitstring-status-list#105
ivan: pr 105??
manu: what is the vocabulory URL for the status list?
… several proposals for this
<manu> This could be one of the vocabulary URL prefixes: https://
<manu> This could be one of the vocabulary URL prefixes: https://
manu: we need to pick one and go with it
<manu> This could be one of the vocabulary URL prefixes: https://
manu: but does not align with 2018 existing terms
… should there be a date in the terms or not?
<Zakim> manu, you wanted to note that V2 context is: https://
brentz: do we want to have a poll on the name?
<manu> POLL: What should the status list vocabulary URL be Choice A) https://
<ivan> B
<manu> A
<andres> A
<brentz> A
<pdl_asu> A
B
<pauld_gs1> A
<JoeAndrieu> B
<Kevin-Dean-GS1> A
<manu> DavidC: The reason I wanted the date is if you want to change a definition, if you have date in there, change in definition could have a new date. I see how you can append/remove, but changing them is not possible.
<TallTed> I don't fully grok the pros and cons. A `ns` vs B `2018` (which is when the original VCWG started)
<manu> ivan: There might be a version in the vocabulary, but URL does not change.