Verifiable Credentials Working Group Telco — Minutes

Date: 2024-06-05

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, Hiroyuki Sano, Greg Bernstein, Przemek Praszczalek, Dmitri Zagidulin, Benjamin Young, Manu Sporny, Geunhyung Kim, Wesley Smith, Dave Longley, Ted Thibodeau Jr., Jennie Meier, Phillip Long, Gabe Cohen, David Lehn

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Wesley Smith

Content:

Brent Zundel: First topic today is a test suite readout, status update on various test suites, functional test suites needed to demonstrate specs have been implemented.

Brent Zundel: after that, discuss future timing for each spec and move into work item status updates - primarily pull requests on VCDM.
… as time permits, issue processing on VCDM to progress that specification.

1. Charter.

Ivan Herman: a few words about the charter, I will merge the outstanding PR discussed last week or two weeks ago on the charter, the problems seem to be resolved, I will restart the process and hopefully get a formal vote request.

2. Test suite readout.

Brent Zundel: next topic, test suite readout, Manu on the queue.

Manu Sporny: update on where we are on test suites that Digital Bazaar is working on. Benjamin, would you mind giving us an update.

Benjamin Young: ends related test suites (sd and rdfc) are complete and ready for implementation, the ed25519 tests haven’t changed much, eddsa is also ready, the bbs test suites are hopefully ready to go next week or the week after that. On the horizon is BitstringStatusList.

Brent Zundel: that leaves us with vc-json-schema, vc-jose-cose, and controller document test suites.

Gabe Cohen: currently my company is the only implementer for vc-json-schema, for vc-jose-cose we are starting on an implementation, if interested in implementing either please reach out.

Greg Bernstein: one breaking change, will rev the document with the last breaking change prior to 7/20 IETF meeting, as far as timing test suites, giving folks a heads up.

Manu Sporny: not possible to implement data integrity specs without implementing the vast majority of the controller document specs, we have tested the normative statements in the specs with didcore 1.0, 1.1, don’t need a controller document test suite as it is being tested elsewhere. If that is not true in some cases, we could add tests to the Data Integrity test suites that would test those aspects of controller document. Good arguments that the majority of controller document tests already done.

Ivan Herman: fine with what Manu said, but more general question - how will the reporting be done knowing that we are talking about 8 different specs, should go to PR together bc of interdependencies.
… will the reporting be relatively uniform, don’t want multiple ways of reporting so re.

Manu Sporny: https://w3c.github.io/vc-di-ed25519signature2020-test-suite/#conformance.

Manu Sporny: all test suites that digital bazaar is working on generates a test report in unified format.
… just linked to test suite outputs, format should be familiar, we list every normative statement and their implementers.
… implementers can opt in for features, we test all normative statements, for all test suites mentioned this is the format.

Brent Zundel: gabe, my understanding is your test suites will look the same as digital bazaar’s.

Gabe Cohen: yes, our format is similar to digital bazaar’s.

Gabe Cohen: https://w3c.github.io/vc-json-schema-test-suite/.

3. Timing for each of the specs.

Brent Zundel: we have 9 rec-track specifications in process, for the VCDM 2.0, DI, DI-BBS, VC-JOSE-COSE.
… plan a 2nd CR immediately following TPAC.
… on track to publish those as recs by the time the charter is up in January.
… do we need a 2nd CR for ecdsa/eddsa?

Manu Sporny: should count on 2nd CR for those specs as well, new issues might move things around (Multikey).

Brent Zundel: do we anticipate a 2nd CR for vc json schema?

Gabe Cohen: possibly, depends on 2nd implementer we get, if json schema wrapped as credential doesn’t get 2nd imp will need to cut.

Brent Zundel: 2nd CR for BitstringStatusList?

Manu Sporny: count on it again, won’t know until 1st round of implementations, don’t expect needing to cut anything, but count on 2nd CR.

Brent Zundel: controller document - in order for timing to work for relying specs, need to go to 1st CR in August, will not have time for 2nd CR.

Manu Sporny: safe bet, should be able to do controller document on that timeframe.

Ivan Herman: timing wise, I presume the goal is that we make the decisions about 2nd CR at TPAC, can do some of the admin there.

4. Work Item Status Updates/PRs.

Brent Zundel: next topic is work item status updates and PRs, if you are the editor of a work item and would like to bring up PRs please queue.
… note that thanks to heroic efforts of its editors, controller document has been made ready for horizontal review.
… thanks to Manu for filling out sections like security/privacy considerations.

Ivan Herman: two editorial PRs merged for overview document, one more pending with new section, I presented internally at W3C last week.
… and based the presentation on the overview document, clear need for this document, want to vote on going to a note with it.

Greg Bernstein: +1.

Ivan Herman: would like to merge the last PR and start process of moving to note as soon as positive vote.

Proposed resolution: Publish VC Overview as a WG Note with a shortname of vc-overview. (Brent Zundel)

Brent Zundel: any other changes necessary for the proposal?

Ivan Herman: no.

Manu Sporny: +1.

Ted Thibodeau Jr.: +1.

Ivan Herman: +1.

Wesley Smith: +1.

Brent Zundel: +1.

David Lehn: +1.

Greg Bernstein: +1.

Dave Longley: +1.

Benjamin Young: +1.

Phillip Long: +1.

Geunhyung Kim: +1.

Hiroyuki Sano: +1.

Gabe Cohen: +1.

Resolution #1: Publish VC Overview as a WG Note with a shortname of vc-overview.

Manu Sporny: gonna do VCDM last because it has a ton of PRs, an update on the Data Integrity specs, Wes-Smith has raised a number of new PRs.
… discussion there needs to happen, we have 18 issues on VCDI, many editorial, take a look at those PRs, don’t need to go through each.
… there was an issue that was brought up that we need input on having to do with the controller document spec.

4.1. Editorial comments on the Multikey definition(s) (issue vc-data-integrity#268)

See github issue vc-data-integrity#268.

Manu Sporny: Ivan raised a question around an editorial change, we define Multikey in DI spec but not every key type, defns of key types deferred to cryptosuites.
… done historically before controller document spec.
… Ivan argued for moving all defns to central place (DI spec).
… now that we have controller document and group is committed to taking that to rec, key defns should go in controller document.
… as controller document defines verification methods and verification relationships.
… concrete suggestion: take key defns out of wherever they are, centralize them in controller doc, have other specs ref that.

Ivan Herman: one more argument for doing that, my understanding is that Multikey is something that is meant to be used independently of VCs.
… not a credential dependent thing, just an alternative way of representing keys.
… having them not buried in crypto suite documents way better, and controller document is perfect place.

Brent Zundel: thoughts on the proposal, which is to move Multikey representations for DI subspecs into controller document.

Phillip Long: +1 from here.

Gabe Cohen: not a good idea, Multikey is a confusing format, unless we define the specific key types we want to implement, causes divergence.
… should avoid that complexity.

Manu Sporny: would that objection come from you or from Mike Jones?

Gabe Cohen: I am sympathetic to Mike’s position but would not object to including multikey.

Dave Longley: +1 to express the specific key types (like we’re doing now), but be sure we don’t close out extensibility in the future in some way.

Manu Sporny: there seems to be a misguided argument against the multiformats that they aren’t making choices when they are.
… defining base encoding and key formats very specifically.
… one of Mike’s arguments is that we are not making decisions but we are.

Brent Zundel: where have multiformats been specified.

Manu Sporny: multibase, multihash, multikey originally defined in DI specs and cryptosuites, multibase and multihash moved to controller document spec.
… want to do the same for Multikey but expect opposition from Mike.
… Mike has objected to multiformats at IETF, we expect that, we have more than the minimum implementers.

Dmitri Zagidulin: I’m one of the implementers of Multikey, what is the downside of not moving the Multikey defn to controller document?
… agree with Ivan that it’s useful generally not just for VCs, as general key serialization format.

Manu Sporny: it would be better to do that dmitriz, but would be new document this group would have to publish through opposition.
… work to march it through the W3c process, lots of procedural work to achieve same thing.
… current status, consolidate defns across documents to one place, group is OK with that place being controller document.
… in the future, expect a group to think it’s weird that multiformats are in controller document, should be own spec.
… but that is for future group to decide.

Dmitri Zagidulin: makes sense, thanks.

Brent Zundel: final question, is there also a multiformats group working on implementations, is that a group that needs to be consulted?

Manu Sporny: they are not all here but they have been consulted, just so folks know, multihash and multibase have had 17+ implementations for years.
… all we are doing is reusing existing implementations, writing it down in a W3C spec.
… were going to define these things at IETF as RFCs but Mike Jones objected to the work and now everyone is confused about it there.
… the effort it would take to unconfuse things at IETF is significant, we already have implementations, and the implementers.
… in this group are reusing off-the-shelf multihash, multibase, multikey.
… to answer Brent, there are plenty of implementations, implementers in this group using off the shelf formats, don’t need to reach out to other groups.
… what we don’t do in this group is registry, multiformats community has big registry, we are picking and choosing a few to spec at W3c.

5. VCDM Pull Requests.

Brent Zundel: https://github.com/w3c/vc-data-model/pulls.

Manu Sporny: 11 open PRs on VCDM, just gonna hit the highlights,.

5.1. Update media types to application/vc and application/vp (pr vc-data-model#1478)

See github pull request vc-data-model#1478.

Manu Sporny: I need a determination from the WG on what media type we will use.
… talked about this a week ago, have not heard back from IETF registration on if they are accepting our media type.
… don’t think reg will go through, do we want to wait until they reject registration to merge 1478 and pick media type they will accept.

Brent Zundel: that was path we agreed to last time we had this conversation, has anyone changed their mind since then.

Ivan Herman: will we at least get an explicit refusal?

Manu Sporny: can push them for explicit refusal.

Brent Zundel: mike jones pushed them, claimed that silence was acceptance.

Manu Sporny: thank you Brent for a reminder, I had forgotten we had agreed on this, waiting on them for rejection.
… doesn’t sound like anyone has changed their mind.

5.2. Use digestMultibase with base64-url-nopad encoding for integrity. (pr vc-data-model#1490)

See github pull request vc-data-model#1490.

Manu Sporny: other thing we need to decide on is what digest formats we will support for related resource formats.
… only support digestSri has objections that would turn into formal objections, same with only supporting digestMultibase.

See github pull request vc-data-model#1492.

Manu Sporny: have not heard if anyone would formally object to supporting both, is in PR 1492.
… at this point, need to ask group if anyone would object to supporting both digestSRI and digestMultibase.

Brent Zundel: the two options that are before the group that have a chance of avoiding formal objection are.
… a, get rid of description of related resource.
… b, support both, allow implementations to choose on digestSRI vs digestMultibase.
… people don’t like option b, but does anyone dislike it enough to formally object?

Phillip Long: +1 to let the market decide.

Brent Zundel: not hearing or seeing anyone object to the option to include both.
… that is what we have decided to do.

Manu Sporny: thank you, we will merge 1492, supporting both formats, to give more data to the group. I had to implement this this past weekend and it took 30min.
… had to update respec-vc to generate hashes in both formats, took 30 mins, was not difficult.

Ted Thibodeau Jr.: which digest form were you adding?

Manu Sporny: both, added support for every variation of both digest formats.

Brent Zundel: additional PRs we should look at?

Manu Sporny: yes, next set, 6 of these to remove at risk issue markers (confidenceMethod, renderMethod, refreshService, terms of use).

5.3. Removing at risk issue markers.

See github pull request vc-data-model#1495.

See github pull request vc-data-model#1496.

See github pull request vc-data-model#1497.

See github pull request vc-data-model#1498.

Manu Sporny: 1495, 1496, 197, 1498, each one of these either reserves terms (confidenceMethod, renderMethod), don’t have time to finish them but will reserve terms.
… remove terms of use.
… had it in the spec before, not enough implementations, keep term reserved but remove section from spec.
… for all others, enough implementations based on criteria previously agreed on to keep them in spec.
… refresh service and evidence kept in spec, reserve confidenceMethod and renderMethod.

Brent Zundel: the course this group agreed to at the beginning on extension points, agreed that if implementers exist using these extensions we will keep them in the spec.
… these PRs are an expression of that intent, at this point it would be inappropriate to challenge the intent.
… if you have qualms about the PRs it would be inappropriate to be about their course.
… all are welcome to change their mind but hopefully people stay the course here.

Ivan Herman: my issue is timing not intent, as I said at the beginning of this call, the charter/proposal that goes out says that there is an exception for terms that are at risk but in the spec.
… if I go out to the AC now and there is no at risk feature in the spec we have a problem.
… propose we agree with the PRs but do not merge them before the vote is out at the AC.

Manu Sporny: +1, I think we can wait, there will just need to be some maintenance on the PRs.

Brent Zundel: any other PRs we need to look at.

5.4. Auto-generate context and vocabulary digests. (pr vc-data-model#1499)

See github pull request vc-data-model#1499.

Manu Sporny: just a heads up on another PR (1499), we have an extension to respec that allows us to autogenerate these hashes.
… the group said we would like these hashes to be easily generated by command line tool.
… easiest thing to do is hex digest of openSSL command.
… if folks don’t like this approach please make it known in the PR.
… this also makes it so we don’t need to keep syncing the hex digests, guaranteed they will match what is published for context/vocab files.
… I will assert that we are in pretty good shape to be done with this specification, maybe a handful of leftover issues.
… once those are addressed I am asserting that we are pretty much done unless something amazing comes up.
… one modulo to that is the security disclosure we are waiting on.

6. VCDM Issue Processing.

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

Brent Zundel: last topic is VCDM issue processing, we have time for one of these.
… talk briefly about 1481.

6.1. Suggest to make explicit reference to the JADES standard (issue vc-data-model#1481)

See github issue vc-data-model#1481.

Brent Zundel: suggestion to make explicit reference to JADES standard.
… request is to have an example in our spec of how to do this.

Manu Sporny: I prefer not to include a big example, things signed with JADES are like 100KB blobs, adding an example would not demonstrate anything.

Dmitri Zagidulin: can we /link/ to a JADES example?

Manu Sporny: request to normatively say it is totally fine to use JADES, we shouldn’t do that either.
… we do in the spec mention a variety of other securing formats, we mention JWT, CWT, mDL, Gordian Envelopes, etc, can add JADES to list.

Brent Zundel: +1 to adding to that list.

Brent Zundel: proposal is to link to JADES as we have linked to other securing mechanisms.

Phillip Long: +1 to that.

Brent Zundel: if you are opposed jump into the issue and tell us, otherwise that is what we will do.
… thanks to all for being here.

Ivan Herman: +1 for me as well.

7. Resolutions