Verifiable Credentials Working Group Telco

Meeting minutes

<ivan> Date: 2024-03-06

brent: Welcome. The agenda is straightforward. Status updates, pull requests, and then issues on the core data model.
… anyone have changes or additions?

manu: just 2 announcements about upcoming maintenance deadlines
… as folks know, we made a call for DID and VC registries

<manu> Volunteer list is here: https://lists.w3.org/Archives/Public/public-vc-wg/2024Mar/0005.html

manu: we need volunteers, and did a training video, collected github handles, etc.
… these folks are all more than qualified to maintain the registries
… and they've mostly signed up for both
… we sent an email out to get confirmation from the group on the list of volunteers
… next Tuesday is the deadline to object

Work Item Status Updates/PRs

brent: any comments on volunteering?
… k. status updates. Please queue up if you have updates

manu: for Data Integrity, all the specs are aligned with Jeffrey Yaskin's cryptosuite interface proposal
… it was a major change, so we need to go through another CR
… no negative feedback from implementers
… for BBS, we can go into CR by next week (in theory)

<manu> w3c/vc-di-bbs

manu: Greg still has some pending PRs
… once those are in we'll cut a pre-CR and do a call for consensus
… ivan, I don't know what the timing would be. This is just a heads up that this is nearly ready for a vote.

<manu> https://github.com/w3c/vc-bitstring-status-list/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR

manu: Bitstring Status List can be ready for a vote to got into CR early next month
… we have asked PING to review prior to CR...still waiting on confirmation
… we have had reviews done and other reviews will timeout in mid-April
… the big thing we need is what the Traceability group is doing with status list
… but we need more engagement specifically from Transmute and Mesur
… we have a plan for what we can do with it, but we need implementer feedback from the Traceability cohort
… the VCDM has a few changes related to requests from the Activity Pub folks
… but the standing issues seem to be nearly resolved
… there's a normative change about "enveloped" Verifiable Presentations
… just to be clear, the VCDM can now carry _any_ payload of _any_ media type
… which means it could hold other forms of credentials, mDoc, etc.
… there's a clear story around how this can be done
… I think this achieves the "big tent" approach we've been aiming at
… the rest of everything seems to be editorial
… what we're targeting is a May timeframe for VCDM
… and we may be able to push it up a bit

<Zakim> ivan, you wanted to talk about CR timing

brent: ivan?

ivan: do we want to talk about CR timing now?

brent: now's good

ivan: for the March date, we have to take into consideration that the timing lines up with Good Friday, which means one of our reviewers will be on vacation
… and the 5th of April is a publication moratorium due to the AC meeting in Japan
… so if we can't get this request in by next week or the beginning of the week of the 18th, then it won't happen in March
… additional difficulty is that from March 22-26 I will be out of town

<Zakim> manu, you wanted to discuss CR timing windows... shoot for beginning of week of 18th.

manu: sounds like we should shoot for the 18th of March

ivan: when would the WG get together? the 13th? next week?

manu: I can check with Greg to see if he has anything else that needs to go in
… otherwise, I think we can do it by next week
… it's all stuff that's already in the spec, just some of it will become normative
… most of it has been there for weeks or even months
… we can set the publication for the 21st

ivan: I admire your optimism. If we vote on the 13th, we'd need an approval by the 15th--2 days later--and that seems unlikely

manu: when's the better day?

ivan: the 26th or the 28th

manu: 28th? would that work?
… that would be for BBS or JOSE/COSE? or both?

ivan: the difference between one or two is marginal, so having both together would be best

manu: I'll work with Greg to prep for a vote on the 13th
… we'll target a publication date of the 28th

brent: Gabe or Mike Jones, any updates on JOSE/COSE

selfissued: we have no open PRs

<selfissued> w3c/vc-jose-cose#206

selfissued: but we do have some issues

w3c/vc-jose-cose#206

selfissued: 206 is about the verification algorithm
… but manu's already mentioned that all the specs are doing the right thing in terms of algorithm

manu: I wasn't referring to JOSE/COSE, just the Data Integrity specs
… I think the editors of JOSE/COSE should figure out if the new interfaces apply for create and verify
… I'm checking to see what Jeffrey wrote about this earlier

<manu> https://w3c.github.io/vc-data-model/#securing-mechanism-specifications

manu: section 5.13 securing mechanism specifications
… I don't know if the VC JOSE/COSE spec does the things that section requires
… it must provide a verification method that only contains the data in the document
… there are a bunch of other requirements for embedded proofs
… but no real requirements for enveloping proofs
… it's up to the editors to decide if they've hit that bar
… and the group to agree or not

selfissued: brent, this is assigned to you, do you want to keep it

brent: yes. I'll keep it

decentralgabe: we have a section on this, but the rendering is broken

brent: I'll look at that as welll

manu: there's a bulleted list in the issue I made. I've not seen responses
… I'll not block this going into CR, but without these changes it's likely to get formally rejected
… so, going through the list and explaining how they're addressed should help avoid the formal objection and close that issue

selfissued: you mean the one from December?

manu: yes.

brent: I'll tackle this
… anything else about JOSE/COSE?

selfissued: decentralgabe has the other issues

decentralgabe: I plan to do both this week

<selfissued> The three vc-jose-cose before-CR issues are https://github.com/w3c/vc-jose-cose/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR

brent: if all three of these are addressed with PRs, it's theoretically possible we could vote next week...but that seems really tight

selfissued: no opinion on timing, ivan's the expert

VCDM Issue Processing

<brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc

brent: 1437 is our first one

w3c/vc-data-model#1442

brent: oh, this is before PR, so we'll skip it for now

brent: 1442 is assigned to ivan

manu: just to provide some input
… ivan asked about posting the canonical hash
… what we want is for people to retrieve something from the Web, and pass it through a library to get the hash
… telling people to have something special on hand to tell if the doc is valid is not what we want
… using a format they can read, SHA it, and compare would be better
… we could add hashes for every serialization, but that feels like a bit much
… we do want to update our ReSpec extension to generate these hashes at publication time

ivan: it was already clear back then that the hash is the representation of the JSON-LD of the vocabulary

manu: yes

ivan: depending on conneg, you may get other formats
… it's not clear enough that the hash is specifically for the `application/ld+json` representation

manu: I thought we had examples of how to recreate the hashes

ivan: it's there, but it's still not clear
… make it clear. should only be a few words

brent: currently this is assigned to you, ivan

ivan: I can make a PR

w3c/vc-data-model#1197

manu: thank you ivan!

brent: moving on to 1197
… Nick Steele agreed to do the work, but he's not been on the calls

manu: I can take this one

brent: need any clarity from the group?

manu: nope. pretty straightforward

w3c/vc-data-model#1359

brent: 1359
… decentralgabe this is assigned to you

decentralgabe: I still think it'd be helpful for this to be described in the spec
… when you're going to make a VP, how can you be sure that the entity presenting it is authorized to present it
… so we avoid anyone presenting it to anyone

manu: +1. I do think we can point to the confidence method spec
… the only concern I have is that the spec hasn't been touched in awhile
… I do think we plan to revisit it in a future WG, but not sure we want to talk about it before then

<TallTed> having a VC property for "authorized presenters" seems a fine extension, but what to do with it feels like business logic

manu: we could talk about matching DIDs and comparing crypto related to those at each layer
… it's really when you want to connect it to a additional binding mechanisms that you'd want confidence method to come in

brent: a full treatment of this seems too much to handle right now

<manu> I agree with Brent's overall analysis. What can we do editorially for this?

brent: what aspect of this would fit right now, is my question to decentralgabe
… we've got general interest in closing this, but we should narrow in on a specific recommendation

decentralgabe: I'd like to see non-normative text about it that could later be made normative
… it would at least help nudge people toward the future

brent: is this something you can do?

decentralgabe: yes, but it's lower priority

<Zakim> TallTed, you wanted to say having a VC property for "authorized presenters" seems a fine extension, but what to do with it feels like business logic

brent: I will note you assigned it to yourself in December, and it's still yours to do

TallTed: I'm still very unclear how confidence method applies to who's presenting

<manu> I agree with Ted's analysis.

<decentralgabe> will attempt some language, looking forward to it being torn apart :)

TallTed: it does feel reasonable to say "these are my authorized presenters", but how to enforce that feels like business logic to me

selfissued: how do you see this list interacting with proof of possession binding?

decentralgabe: that's one option, but there be situations where that's not present

selfissued: just wanted to note they were related

w3c/vc-data-model#1254

brent: 1254 is about complex language markup
… this was pending close
… we got a comment that if the title is adjusted, that would better apply or reflect the content
… sounds like a simple change

manu: I'll take it
… and just try to work with title, since Sebastien's no longer with us
… I'll provide a PR and we can talk about it there

w3c/vc-data-model#1432

brent: 1432
… this is assigned to decentralgabe. Do you need input?

<dlongley> it might be a bad idea for "personal credentials" (credentials about people)

decentralgabe: could I state that public URLs for credentials is a Bad Thing, and suggest we recommend URNs would be better

manu: I think we should not do that, but state that it's nuanced
… there are all sorts of credentials that should use the ID
… and many that should not state an ID--when they're for private individuals, etc.
… we may want to put this in the Privacy section--and it may already be covered

<dlongley> +1 to what the credential is about should be a strong consideration on what ID/what kinds of IDs you might use.

<decentralgabe> +1 Manu, understood

pauld_gs1: we do use resolvable URIs for public credentials
… if it's PII, then there are reasons not o
… but there are certainly reasons to use public URIs
… and I do think it's already in the Privacy section

selfissued: there are cases where we use these, and without them key discovery breaks

brent: did that help?

decentralgabe: yes. I'll incorporate it into a PR