14:42:39 <RRSAgent> RRSAgent has joined #vcwg
14:42:43 <RRSAgent> logging to https://www.w3.org/2024/06/05-vcwg-irc
14:42:43 <Zakim> inviting RRSAgent
14:42:43 <Zakim> RRSAgent, make logs Public
14:42:44 <Zakim> please title this meeting ("meeting: ..."), ivan
14:42:59 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:42:59 <ivan> Date: 2024-06-05
14:42:59 <ivan> Agenda: https://www.w3.org/events/meetings/0c00c874-8356-4700-b8c6-5d7f9eab1792/20240605T110000/
14:42:59 <ivan> chair: brent
14:43:00 <ivan> ivan has changed the topic to: Meeting Agenda 2024-06-05: https://www.w3.org/events/meetings/0c00c874-8356-4700-b8c6-5d7f9eab1792/20240605T110000/
14:54:54 <brent> brent has joined #vcwg
14:55:01 <brent> present+
14:55:56 <ivan> present+
14:58:07 <GregB> GregB has joined #vcwg
14:58:16 <hsano> hsano has joined #vcwg
14:58:35 <hsano> hsano has joined #vcwg
14:59:18 <Przemek> Przemek has joined #vcwg
14:59:37 <hsano> present+
14:59:53 <ivan> present+ gregb
14:59:59 <GregB> present+
15:00:17 <ivan> present+ Przemek
15:01:37 <ivan> present+ dmitriz, bigbluehat, manu
15:01:56 <ivan> present+ Geunhyung
15:02:12 <ivan> present+ wesley
15:02:42 <ivan> scribe+ wesley
15:03:38 <dmitriz> dmitriz has joined #vcwg
15:03:54 <Geun-Hyung> Geun-Hyung has joined #vcwg
15:04:19 <Wes-Smith> Wes-Smith has joined #vcwg
15:04:32 <Wes-Smith> scribe+
15:04:43 <TallTed> TallTed has joined #vcwg
15:04:50 <dlongley> present+
15:04:51 <ivan> present+ TallTed
15:05:20 <Geun-Hyung> present+
15:05:28 <bigbluehat> bigbluehat has joined #vcwg
15:05:59 <ivan> present+ jennie
15:06:01 <Wes-Smith> Brent: First topic today is a test suite readout, status update on various test suites, functional test suites needed to demonstrate specs have been implemented
15:06:26 <ivan> q+
15:06:29 <PL-ASU> PL-ASU has joined #vcwg
15:06:29 <Wes-Smith> ... after that, discuss future timing for each spec and move into work item status updates - primarily pull requests on VCDM
15:06:35 <PL-ASU> present+
15:06:48 <Wes-Smith> ...as time permits, issue processing on VCDM to progress that specification
15:06:53 <brent> brent has joined #vcwg
15:06:58 <brent> q?
15:07:04 <brent> ack ivan
15:07:20 <Przemek> Przemek has joined #vcwg
15:07:24 <decentralgabe> decentralgabe has joined #vcwg
15:07:28 <brent> Topic: Charter
15:07:29 <decentralgabe> present+
15:08:13 <Wes-Smith> Ivan: 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
15:08:27 <brent> Topic: test suite readout
15:08:29 <manu> q+
15:08:34 <brent> ack manu
15:08:37 <Wes-Smith> Brent: next topic, test suite readout, Manu on the queue
15:08:48 <ivan> present+ gabe
15:08:57 <Wes-Smith> Manu: update on where we are on test suites that Digital Bazaar is working on. Benjamin, would you mind giving us an update
15:10:42 <Wes-Smith> bigbluehat: 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.
15:10:42 <decentralgabe> q+
15:10:52 <GregB> q+
15:11:05 <Wes-Smith> brent: that leaves us with vc-json-schema, vc-jose-cose, and controller document test suites
15:11:07 <brent> ack decentralgabe
15:11:09 <manu> q+ to speak to controller document tests.
15:11:44 <Wes-Smith> decentralgabe: 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
15:11:49 <brent> ack GregB
15:11:56 <ivan> q+ to ask about reporting
15:12:40 <brent> ack manu
15:12:40 <Zakim> manu, you wanted to speak to controller document tests.
15:12:53 <Wes-Smith> GregB: 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
15:14:13 <brent> ack ivan
15:14:13 <Zakim> ivan, you wanted to ask about reporting
15:14:14 <Wes-Smith> manu: 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
15:14:14 <Wes-Smith> Integrity test suites that would test those aspects of controller document. Good arguments that the majority of controller document tests already done
15:14:41 <manu> q+ on reports
15:16:08 <brent> ack manu
15:16:08 <Zakim> manu, you wanted to comment on reports
15:16:11 <Wes-Smith> Ivan: 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
15:16:13 <Wes-Smith> ...will the reporting be relatively uniform, don't want multiple ways of reporting so re
15:16:14 <manu> https://w3c.github.io/vc-di-ed25519signature2020-test-suite/#conformance
15:16:28 <Wes-Smith> manu: all test suites that digital bazaar is working on generates a test report in unified format
15:16:49 <Wes-Smith> ...just linked to test suite outputs, format should be familiar, we list every normative statement and their implementers
15:17:13 <Wes-Smith> ...implementers can opt in for features, we test all normative statements, for all test suites mentioned this is the format
15:17:39 <Wes-Smith> Brent: gabe, my understanding is your test suites will look the same as digital bazaar's
15:17:52 <Wes-Smith> gabe: yes, our format is similar to digital bazaar's
15:17:55 <decentralgabe> https://w3c.github.io/vc-json-schema-test-suite/
15:18:04 <brent> Topic: Timing for each of the specs
15:18:41 <Wes-Smith> Brent: we have 9 rec-track specifications in process, for the VCDM 2.0, DI, DI-BBS, VC-JOSE-COSE
15:18:52 <Wes-Smith> ...plan a 2nd CR immediately following TPAC
15:19:02 <Wes-Smith> ...on track to publish those as recs by the time the charter is up in January
15:19:04 <Przemek> Przemek has joined #vcwg
15:19:16 <manu> q+
15:19:24 <brent> ack manu
15:19:27 <Wes-Smith> ...do we need a 2nd CR for ecdsa/eddsa
15:19:43 <Wes-Smith> manu: should count on 2nd CR for those specs as well, new issues might move things around (Multikey)
15:19:57 <Wes-Smith> Brent: do we anticipate a 2nd CR for vc json schema?
15:20:49 <Wes-Smith> decentralgabe: possibly, depends on 2nd implementer we get, if json schema wrapped as credential doesn't get 2nd imp will need to cut
15:20:52 <manu> q+
15:20:55 <brent> ack manu
15:20:59 <Wes-Smith> Brent: 2nd CR for BitstringStatusList?
15:21:17 <Wes-Smith> Manu: count on it again, won't know until 1st round of implementations, don't expect needing to cut anything, but count on 2nd CR
15:21:37 <Wes-Smith> Brent: 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
15:21:38 <manu> q+
15:21:43 <brent> ack manu
15:21:57 <ivan> q+
15:21:58 <Wes-Smith> Manu: safe bet, should be able to do controller document on that timeframe
15:22:05 <brent> ack ivan
15:22:09 <dlehn> present+
15:22:40 <Wes-Smith> Ivan: timing wise, I presume the goal is that we make the decisions about 2nd CR at TPAC, can do some of the admin there
15:22:49 <brent> Topic: Work Item Status Updates/PRs
15:23:01 <ivan> q+
15:23:06 <manu> q+
15:23:12 <Wes-Smith> Brent: 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
15:23:27 <Wes-Smith> ...note that thanks to heroic efforts of its editors, controller document has been made ready for horizontal review
15:23:42 <Wes-Smith> ...thanks to Manu for filling out sections like security/privacy considerations
15:23:55 <brent> ack ivan
15:24:28 <Wes-Smith> Ivan: two editorial PRs merged for overview document, one more pending with new section,  I presented internally at W3C last week
15:24:44 <Wes-Smith> ...and based the presentation on the overview document, clear need for this document, want to vote on going to a note with it
15:24:53 <GregB> +1
15:25:19 <Wes-Smith> Ivan: would like to merge the last PR and start process of moving to note as soon as positive vote
15:25:48 <brent> PROPOSAL: Publish VC Overview as a WG Note with a shortname of vc-overview
15:25:50 <Wes-Smith> Brent: any other changes necessary for the proposal?
15:25:52 <Wes-Smith> Ivan: no
15:25:53 <manu> +1
15:25:54 <TallTed> +1
15:25:55 <ivan> +1
15:25:56 <Wes-Smith> +1
15:25:56 <brent> +1
15:25:57 <dlehn> +1
15:25:57 <GregB> +1
15:25:57 <dlongley> +1
15:25:57 <bigbluehat> +1
15:25:58 <PL-ASU> +1
15:26:00 <Geun-Hyung> +1
15:26:01 <hsano> +1
15:26:02 <decentralgabe> +1
15:26:11 <PL-ASU> q+
15:26:25 <brent> RESOLVED: Publish VC Overview as a WG Note with a shortname of vc-overview
15:26:35 <brent> ack manu
15:26:51 <PL-ASU> q-
15:27:01 <Wes-Smith> Manu: 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
15:27:21 <Wes-Smith> ...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
15:27:42 <Wes-Smith> ...there was an issue that was brought up that we need input on having to do with the controller document spec
15:27:42 <manu> subtopic: https://github.com/w3c/vc-data-integrity/issues/268
15:28:12 <Wes-Smith> ...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
15:28:19 <Wes-Smith> ...done historically before controller document spec
15:28:26 <ivan> q+
15:28:31 <Wes-Smith> ...Ivan argued for moving all defns to central place (DI spec)
15:28:47 <Wes-Smith> ...now that we have controller document and group is committed to taking that to rec, key defns should go in controller document
15:29:00 <Wes-Smith> ...as controller document defines verification methods and verification relationships
15:29:24 <Wes-Smith> ...concrete suggestion: take key defns out of wherever they are, centralize them in controller doc, have other specs ref that
15:29:52 <brent> ack ivan
15:30:19 <Wes-Smith> Ivan: one more argument for doing that, my understanding is that Multikey is something that is meant to be used independently of VCs
15:30:32 <Wes-Smith> ...not a credential dependent thing, just an alternative way of representing keys
15:30:52 <Wes-Smith> ...having them not buried in crypto suite documents way better, and controller document is perfect place
15:31:00 <manu> q+
15:31:04 <manu> q-
15:31:19 <Wes-Smith> Brent: thoughts on the proposal, which is to move Multikey representations for DI subspecs into controller document
15:31:21 <decentralgabe> q+
15:31:23 <PL-ASU> +1 from here
15:31:29 <brent> ack decentralgabe
15:31:51 <Wes-Smith> decentralgabe: not a good idea, Multikey is a confusing format, unless we define the specific key types we want to implement, causes divergence
15:31:52 <manu> q+
15:31:55 <Wes-Smith> ...should avoid that complexity
15:32:00 <brent> ack manu
15:32:23 <Wes-Smith> Manu: would that objection come from you or from Mike Jones
15:32:37 <Wes-Smith> decentralgabe: I am sympathetic to Mike's position but would not object to including multikey
15:32:49 <manu> q+
15:32:54 <dmitriz> q+
15:32:59 <dlongley> +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.
15:33:00 <brent> ack manu
15:33:17 <Wes-Smith> manu: there seems to be a misguided argument against the multiformats that they aren't making choices when they are
15:33:27 <Wes-Smith> ...defining base encoding and key formats very specifically
15:33:37 <Wes-Smith> ...one of Mike's arguments is that we are not making decisions but we are
15:33:57 <Wes-Smith> Brent: where have multiformats been specified
15:34:31 <Wes-Smith> manu: multibase, multihash, multikey originally defined in DI specs and cryptosuites, multibase and multihash moved to controller document spec
15:34:39 <Wes-Smith> ...want to do the same for Multikey but expect opposition from Mike
15:35:19 <Wes-Smith> Manu: Mike has objected to multiformats at IETF, we expect that, we have more than the minimum implementers
15:35:26 <brent> ack dmitriz
15:35:43 <manu> q+
15:35:44 <Wes-Smith> dmitriz: I'm one of the implementers of Multikey, what is the downside of not moving the Multikey defn to controller document?
15:35:47 <ivan> q+
15:35:58 <Wes-Smith> ...agree with Ivan that it's useful generally not just for VCs, as general key serialization format
15:36:00 <brent> ack manu
15:36:17 <Wes-Smith> manu: it would be better to do that dmitriz, but would be new document this group would have to publish through opposition
15:36:30 <Wes-Smith> ...work to march it through the W3c process, lots of procedural work to achieve same thing
15:36:53 <Wes-Smith> ...current status, consolidate defns across documents to one place, group is OK with that place being controller document
15:37:12 <Wes-Smith> ...in the future, expect a group to think it's weird that multiformats are in controller document, should be own spec
15:37:17 <Wes-Smith> ...but that is for future group to decide
15:37:21 <brent> ack ivan
15:37:23 <Wes-Smith> dmitriz: makes sense, thanks
15:37:31 <Wes-Smith> Ivan: if dmitriz is happy that's fine
15:37:43 <manu> q+
15:37:51 <Wes-Smith> Brent: final question, is there also a multiformats group working on implementations, is that a group that needs to be consulted?
15:37:53 <brent> ack manu
15:38:11 <Wes-Smith> manu: they are not all here but they have been consulted, just so folks know, multihash and multibase have had 17+ implementations for years
15:38:26 <Wes-Smith> ...all we are doing is reusing existing implementations, writing it down in a W3C spec
15:38:45 <Wes-Smith> ...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
15:39:06 <Wes-Smith> ...the effort it would take to unconfuse things at IETF is significant, we already have implementations, and the implementers
15:39:21 <Wes-Smith> ...in this group are reusing off-the-shelf multihash, multibase, multikey
15:39:51 <Wes-Smith> ...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
15:40:17 <Wes-Smith> ...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
15:40:29 <Wes-Smith> Brent: pull requests on VCDM
15:40:32 <brent> https://github.com/w3c/vc-data-model/pulls
15:40:47 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1478
15:40:53 <Wes-Smith> manu: 11 open PRs on VCDM, just gonna hit the highlights, I need a determination from the WG on what media type we will use
15:41:07 <Wes-Smith> ...talked about this a week ago, have not heard back from IETF registration on if they are accepting our media type
15:41:22 <ivan> q+
15:41:30 <Wes-Smith> ...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
15:41:41 <brent> ack ivan
15:41:43 <Wes-Smith> Brent: that was path we agreed to last time we had this conversation, has anyone changed their mind since then
15:41:50 <Wes-Smith> Ivan: will we at least get a refusal
15:41:58 <Wes-Smith> manu: can push them for explicit refusal
15:42:11 <Wes-Smith> Brent: mike jones pushed them, claimed that silence was acceptance
15:42:25 <Wes-Smith> manu: thank you Brent for a reminder, I had forgotten we had agreed on this, waiting on them for rejection
15:42:39 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1490
15:43:00 <Wes-Smith> ...doesn't sound like anyone has changed their mind, other thing we need to decide on is what digest formats we will support for related resource formats
15:43:28 <Wes-Smith> ...only support digestSri has objections that would turn into formal objections, same with only supporting digestMultibase
15:43:39 <manu> support both formats: https://github.com/w3c/vc-data-model/pull/1492
15:43:44 <Wes-Smith> ...have not heard if anyone would formally object to supporting both, is in PR 1492
15:43:59 <Wes-Smith> ...at this point, need to ask group if anyone would object to supporting both digestSRI and digestMultibase
15:44:18 <Wes-Smith> Brent: the two options that are before the group that have a chance of avoiding formal objection are
15:44:29 <Wes-Smith> ...a, get rid of description of related resource
15:44:43 <Wes-Smith> ...b, support both, allow implementations to choose on digestSRI vs digestMultibase
15:44:57 <Wes-Smith> ...people don't like option b, but does anyone dislike it enough to formally object
15:45:17 <PL-ASU> +1 to let the market decide
15:45:26 <Wes-Smith> Brent: not hearing or seeing anyone object to the option to include both
15:45:31 <Wes-Smith> ...that is what we have decided to do
15:45:33 <manu> q+ to agree and move on.
15:45:39 <brent> ack manu
15:45:39 <Zakim> manu, you wanted to agree and move on.
15:46:02 <Wes-Smith> manu: 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
15:46:30 <Wes-Smith> ...had to update respec-vc to generate hashes in both formats, took 30 mins, was not difficult
15:46:42 <Wes-Smith> TallTed: which digest form were you adding?
15:46:53 <Wes-Smith> manu: both, added support for every variation of both digest formats
15:47:17 <Wes-Smith> Brent: additional PRs we should look at?
15:47:42 <brent> q+
15:47:49 <Wes-Smith> manu: yes, next set, 6 of these to remove at risk issue markers (confidenceMethod, renderMethod, refreshService, terms of use)
15:48:15 <manu> subtopic: Removing at risk issue markers
15:48:19 <manu> https://github.com/w3c/vc-data-model/pull/1495
15:48:21 <manu> https://github.com/w3c/vc-data-model/pull/1496
15:48:24 <manu> https://github.com/w3c/vc-data-model/pull/1497
15:48:26 <manu> https://github.com/w3c/vc-data-model/pull/1498
15:48:52 <Wes-Smith> manu: 1495, 1496, 197, 1498, each one of these either reserves terms (confidenceMethod, renderMethod), don't have time to finish them but will reserve terms
15:49:02 <Wes-Smith> ...remove terms of use
15:49:18 <Wes-Smith> ...had it in the spec before, not enough implementations, keep term reserved but remove section from spec
15:49:32 <Wes-Smith> ...for all others, enough implementations based on criteria previously agreed on to keep them in spec
15:49:57 <ivan> q+
15:49:59 <brent> ack brent
15:50:00 <Wes-Smith> ...refresh service and evidence kept in spec, reserve confidenceMethod and renderMethod
15:50:53 <Wes-Smith> Brent: 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
15:51:06 <Wes-Smith> ...these PRs are an expression of that intent, at this point it would be inappropriate to challenge the intent
15:51:31 <Wes-Smith> ...if you have qualms about the PRs it would be inappropriate to be about their course
15:51:36 <brent> ack ivan
15:51:46 <Wes-Smith> ...all are welcome to change their mind but hopefully people stay the course here
15:52:36 <Wes-Smith> Ivan: 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
15:52:42 <manu> q+ to speak to timing.
15:52:50 <manu> q+ to say we can wait to merge these.
15:52:52 <Wes-Smith> ...if I go out to the AC now and there is no at risk feature in the spec we have a problem
15:53:05 <Wes-Smith> ...propose we agree with the PRs but do not merge them before the vote is out at the AC
15:53:20 <brent> ack manu
15:53:20 <Zakim> manu, you wanted to speak to timing. and to say we can wait to merge these.
15:53:25 <Wes-Smith> manu: +1, I think we can wait, there will just need to be some maintenance on the PRs
15:53:33 <Wes-Smith> Brent: any other PRs we need to look at
15:53:42 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1499
15:53:56 <Wes-Smith> manu: just a heads up on another PR (1499), we have an extension to respec that allows us to autogenerate these hashes
15:54:11 <Wes-Smith> ...the group said we would like these hashes to be easily generated by command line tool
15:54:21 <Wes-Smith> ...easiest thing to do is hex digest of openSSL command
15:54:45 <Wes-Smith> ...if folks don't like this approach please make it known in the PR
15:55:04 <Wes-Smith> ...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
15:55:19 <Wes-Smith> ...I will assert that we are in pretty good shape to be done with this specification, maybe a handful of leftover issues
15:55:37 <Wes-Smith> ...once those are addressed I am asserting that we are pretty much done unless something amazing comes up
15:55:42 <brent> Topic: VCDM Issue Processing
15:55:47 <Wes-Smith> ...one modulo to that is the security disclosure we are waiting on
15:55:47 <dmitriz> dmitriz has joined #vcwg
15:55:47 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc
15:55:58 <Wes-Smith> Brent: last topic is VCDM issue processing, we have time for one of these
15:56:05 <Wes-Smith> ...talk briefly about 1481
15:56:06 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1481
15:56:27 <Wes-Smith> Brent: suggestion to make explicit reference to JADES standard
15:56:38 <Wes-Smith> ...request is to have an example in our spec of how to do this
15:56:49 <manu> q+
15:56:54 <brent> ack manu
15:57:20 <Wes-Smith> manu: I prefer not to include a big example, things signed with JADES are like 100KB blobs, adding an example would not demonstrate anything
15:57:31 <dmitriz> can we /link/ to a JADES example?
15:57:33 <Wes-Smith> ...request to normatively say it is totally fine to use JADES, we shouldn't do that either
15:58:00 <Wes-Smith> ...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
15:58:05 <brent> +1 to adding to that list
15:58:27 <Wes-Smith> Brent: proposal is to link to JADES as we have linked to other securing mechanisms
15:58:37 <PL-ASU> +1 to that
15:58:38 <Wes-Smith> ...if you are opposed jump into the issue and tell us, otherwise that is what we will do
15:58:42 <Wes-Smith> ...thanks to all for being here
15:58:45 <ivan> +1 for me as well
15:58:54 <ivan> rrsagent, draft minutes
15:58:55 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/05-vcwg-minutes.html ivan
15:59:50 <ivan> rrsagent, bye
15:59:50 <RRSAgent> I see no action items