From cd92cc485e22fd0e4f871e636a92ac63fad215f4 Mon Sep 17 00:00:00 2001 From: Ivan Herman Date: Wed, 19 Jun 2024 19:34:01 +0200 Subject: [PATCH] Minutes for June 19 --- _minutes/2024-06-19-vcwg.md | 421 ++++++++++++++++++++++++++++++++++ assets/minute_processing.json | 5 +- assets/nicknames.json | 7 + 3 files changed, 431 insertions(+), 2 deletions(-) create mode 100644 _minutes/2024-06-19-vcwg.md diff --git a/_minutes/2024-06-19-vcwg.md b/_minutes/2024-06-19-vcwg.md new file mode 100644 index 0000000..c8ef36f --- /dev/null +++ b/_minutes/2024-06-19-vcwg.md @@ -0,0 +1,421 @@ +--- +layout: minutes +date: 2024-06-19 +title: Verifiable Credentials Working Group weekly teleconference — 2024-06-19 +json-ld: | + { + "@context": [ + "https://schema.org", + { + "resolution": { + "@id": "https://w3c.github.io/scribejs/vocab/resolution", + "@context": { + "@vocab": "https://w3c.github.io/scribejs/vocab/" + } + }, + "irc": { + "@id": "https://w3c.github.io/scribejs/vocab/irc" + } + } + ], + "@type": "CreativeWork", + "url": "https://www.w3.org/2017/vc/WG/Meetings/Minutes/2024-06-19-vcwg", + "name": "Verifiable Credentials Working Group weekly teleconference — Minutes", + "about": "Verifiable Credentials Working Group weekly teleconference", + "dateCreated": "2024-06-19", + "irc": "vcwg", + "datePublished": "2024-06-19", + "genre": "Meeting Minutes", + "accessMode": "textual", + "accessModeSufficient": "textual", + "encodingFormat": "text/html", + "publisher": { + "@type": "Organization", + "name": "World Wide Web Consortium", + "url": "https://www.w3.org/" + }, + "inLanguage": "en-US", + "recordedAt": { + "@type": "Event", + "name": "Verifiable Credentials Working Group weekly teleconference", + "startDate": "2024-06-19", + "endDate": "2024-06-19", + "location": { + "@type": "VirtualLocation", + "description": "Teleconference" + }, + "attendee": [ + { + "@type": "OrganizationRole", + "roleName": "chair", + "attendee": [ + { + "@type": "Person", + "name": "Brent Zundel" + } + ] + }, + { + "@type": "OrganizationRole", + "roleName": "scribe", + "attendee": [ + { + "@type": "Person", + "name": "KevinDean" + } + ] + }, + { + "@type": "Person", + "name": "Hiroyuki Sano" + }, + { + "@type": "Person", + "name": "David Chadwick" + }, + { + "@type": "Person", + "name": "Manu Sporny" + }, + { + "@type": "Person", + "name": "Kevin Dean" + }, + { + "@type": "Person", + "name": "Paul Dietrich" + }, + { + "@type": "Person", + "name": "jennie Meier" + }, + { + "@type": "Person", + "name": "Jennie Meier" + }, + { + "@type": "Person", + "name": "Dmitri Zagidulin" + } + ] + } + } + +--- + +# Verifiable Credentials Working Group weekly teleconference — Minutes +{: .no_toc .draft_notice_needed} + + + +**Date:** 2024-06-19 + +See also the [Agenda](https://www.w3.org/events/meetings/c9d3c6dc-305d-4ab8-9c97-c3c3faf06240/20240619T110000/) and the [IRC Log](https://www.w3.org/2024/06/19-vcwg-irc.txt) + +## Attendees +{: .no_toc} +**Present:** Hiroyuki Sano, Brent Zundel, David Chadwick, Manu Sporny, Kevin Dean, Paul Dietrich, jennie Meier, Jennie Meier, Dmitri Zagidulin + +**Regrets:** + +**Guests:** + +**Chair:** Brent Zundel + +**Scribe(s):** KevinDean + +## Content: +{: .no_toc} + +* TOC +{:toc} +--- + + +**Brent Zundel:** Don't know why we have media types on there, but will keep it. + +### 1. media types. +{: #section1} + +**Manu Sporny:** Media type working group has a new chair, now two. Email to mailing list. "We are trying to figure out what to do with this multiple suffixes media type, here's where we are.". +… Basically saying that they would like the VC WG to let them know what we would like to see happen with multiple suffixes and media types. They have tried multiple things and none have really worked. What would the VC WG like them to do? +… We need to respond. We don't have enough people today to discuss in the group. +… The only thing that might get consensus in the group is "Here is the way that everyone has used a single '+' sign in the past" and "Here's the way that many groups are using multiple '+' signs". +… It doesn't mean what it has traditionally meant because people thought that multiple suffixes would be used in a way that has not come to pass. +… We have found no example of that in the wild and it's been years. +… I don't think VC WG cares anymore. +… We have found our solution, which is to use a simpler media type and register that. We're moving on. +… Suggest our response to that is that we have moved on and good luck to them on their journey. + +**Brent Zundel:** Multiple suffixes could have been really cool. + +**Ted Thibodeau Jr.:** As one of the early proponents of the multiple '+' signs, IETF is just not functional. Experience with them has left a bad taste. Where we are at with the simple media type, the fallbacks are going to have to be written into software. + +**Brent Zundel:** Who will respond? +… Happy to respond. We appreciate the consideration given over the years. At this point, the VC WG is going to register a simple media type for the models we have developed and leave it at that. +… If people at TPAC want to have a conversation, we can do so. + +### 2. VCDM Issue Processing. +{: #section2} + +**Brent Zundel:** On to VC DM issues. + +> *Brent Zundel:* [https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc](https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc). + +**Brent Zundel:** Only seven open. Many are in the process of being resolved. The goal of this conversation is a quick check-in. How is it going for those that have volunteered to move things forward? +… Not going to talk about 1239. + +#### 2.1. Consider explicitly allowing/recommending language maps for use in internationalisation. (issue vc-data-model#1479) +{: #section2-1} + +_See github issue [vc-data-model#1479](https://github.com/w3c/vc-data-model/issues/1479)._ + + + + + +**Brent Zundel:** First one to look at today is 1479. +… Dmitri, how is it going? + +**Dmitri Zagidulin:** No support required. Hope to have something by Friday. + +**Brent Zundel:** Next is 1462, it's closed, not discussing. + +#### 2.2. Removes the `termsOfUse` section from the specification and reserves the property. (issue vc-data-model#1498) +{: #section2-2} + +_See github issue [vc-data-model#1498](https://github.com/w3c/vc-data-model/issues/1498)._ + + + + + +**Brent Zundel:** Next is 1498. +… PRs are waiting to be merged. If the new charter gets approved, then we can take care of all of this. The only one we should have a conversation about is 1498. + +**David Chadwick:** This week, I have managed to contact EBSI, they will send someone to next week's meeting. They are using the terms of use. Also contacted Lal Chandran, and they confirmed it was being used as well. + +**Brent Zundel:** Reminder to the group. After our last conversation, if we get response from EBSI that they have implemented the spec, then we will be in a good place for anyone to say "Terms of use" is bad and should go away. + +**David Chadwick:** Not sure if they have agreed to participate in the test suite. +… They have implemented VCDM v 1. They may not have yet upgraded so impractical for them to participate in test suite. +… Question for Manu: To the best of my knowledge, nobody is using VPs sent by the holder, so OK to remove that part of the specification. Example in there is spurious. + +**Manu Sporny:** David, why don't you do the removal. + +**David Chadwick:** If I do an edit that removes the VP stuff, then we can accept one of Manu's PRs or mine, and reject the other. + +**Manu Sporny:** Doesn't think the fact that they're using the v1 context matters much, all that matters is that they have written software around it. We will use one of their examples. May run into a problem with their context. +… We will issue a VC that includes the feature and if we get two implementations we will keep the feature. +… Let's see how many implementations they have and if they're committed to using the feature we will keep it. +… There are multiple implementations using v1 already integrated into the test suite so we can test the extension point mechanism. + +**David Chadwick:** All implementations should be able to handle all examples in the spec. Upgraded it from v1 to v2 by changing the context, every implementation should see the terms of use and ignore it if it doesn't recognize the type. + +#### 2.3. Could not define "name" and "description" as attributes of my type (issue vc-data-model#1500) +{: #section2-3} + +_See github issue [vc-data-model#1500](https://github.com/w3c/vc-data-model/issues/1500)._ + + + + + +**Brent Zundel:** Next is 1500. It was a question, last time we talked, we settled on that the question has been answered. +… Not sure what to do with this issue. +… Feels like it would be premature to close it. +… Return to it next week. + +#### 2.4. Comments/Suggestions on Privacy Considerations (issue vc-data-model#1502) +{: #section2-4} + +_See github issue [vc-data-model#1502](https://github.com/w3c/vc-data-model/issues/1502)._ + + + + + +**Brent Zundel:** Next is 1502, comments/suggestions on privacy considerations. +… Manu has assigned himself to raise a PR. +… May have lost Manu, not on Zoom anymore. Just editorial changes. + +#### 2.5. SD-JWT fields in the v2 context should use `"@type": "@json"` (issue vc-data-model#1503) +{: #section2-5} + +_See github issue [vc-data-model#1503](https://github.com/w3c/vc-data-model/issues/1503)._ + + + + + +**Brent Zundel:** Next is 1503. Issues like this are a good sign. Means people are finding little nits like this. +… Dave Longley is not on the call. There need to be a couple of modifications to the context because of this issue. +… Manu assigned 1502 and 1503. + +#### 2.6. Comments/Suggestions on Privacy Considerations (issue vc-data-model#1502) +{: #section2-6} + +_See github issue [vc-data-model#1502](https://github.com/w3c/vc-data-model/issues/1502)._ + + + + + +**Manu Sporny:** 1502 is important because of submission from Electronic Frontier Foundation. +… Happy to raise a PR to address the issue. +… Shouldn't only depend on private browsing mode, also want things to ensure that compliance regimes have guidelines about law enforcement access and that they are transparent to the holder. +… Also want logs that wallets would keep so that holder could see what was shared. +… No objections from group to Manu taking on PR. + +### 3. Controller Document. +{: #section3} + +> *Brent Zundel:* [https://github.com/w3c/controller-document/pulls](https://github.com/w3c/controller-document/pulls). + +**Brent Zundel:** Two PRs. Start with 32. + +#### 3.1. Add section on Controller Document data model. (pr controller-document#32) +{: #section3-1} + +_See github pull request [controller-document#32](https://github.com/w3c/controller-document/pull/32)._ + + + + + +**Manu Sporny:** This replaces a section that was accidentally removed a while ago. We never actually said what we would find in the controller document. Lifted text from DIDCORE with modifications. +… Talks about what are the mandatory and optional properties beyond just verification methods and relationships. +… Some feedback on text from Ivan, some good points but the further we get from what DIDCORE says the harder it is to maintain alignment. +… TallTed's changes are also good. +… Need guidance from the group. Are we going to address Ivan's more fundamental concerns about the PR? + +**Brent Zundel:** Not seeing anyone on the queue. It seems like Ivan's comments might be better addressed as a separate issue rather than as part of this PR. + +**Ted Thibodeau Jr.:** Table changes are also editorial. + +**David Chadwick:** Question to Manu. If the controller property is present and says "Fred and Mary can do this", what does it say about the subject? +… Does the subject still have all the properties as if the controller is absent? + +**Manu Sporny:** If there is no controller field, then the subject is the controller. If there is a controller, I believe that most implementations allow the subject to have the same power. + +**David Chadwick:** Will raise an issue. + +**Manu Sporny:** TallTed, trying to bunch the same description in the fields, will try to fix the table. + +**KevinDean:** Supports the need for clarification of controller. Parents may be controllers of a child's VC without wanting the child to have the same capability. + +#### 3.2. fix grammar, add links (pr controller-document#30) +{: #section3-2} + +_See github pull request [controller-document#30](https://github.com/w3c/controller-document/pull/30)._ + + + + + +**Brent Zundel:** Looking at 30. Call for summary review. +… Editorial fixes, links added. Thanks to TallTed for raising. Nothing controversial. + +> *Brent Zundel:* [https://github.com/w3c/controller-document/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc](https://github.com/w3c/controller-document/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc). + +**Brent Zundel:** On to looking at issues. + +> *KevinDean:* Start with 5. + +#### 3.3. Put publicKeyJwk on an equal footing with publicKeyMultibase (issue controller-document#5) +{: #section3-3} + +_See github issue [controller-document#5](https://github.com/w3c/controller-document/issues/5)._ + + + + + +**Brent Zundel:** Start with 5. +… Put public key JWK on same footing as public key multibase. +… Suggested move forward is to adjust the examples. + +**Manu Sporny:** Fine to add examples. + +**Brent Zundel:** Fine to let this sit for now. +… On to 9. + +#### 3.4. Review sections marked non-normative (issue controller-document#9) +{: #section3-4} + +_See github issue [controller-document#9](https://github.com/w3c/controller-document/issues/9)._ + + + + + +**Brent Zundel:** Far more sections are marked non-normative than other spec. This is an encouragement to review to ensure that they are indeed non-normative. + +**Manu Sporny:** Believes that ReSpec will complain if there is a normative statement in a non-normative section. + +**Brent Zundel:** Agrees that tooling should be of assistance. +… Task here is to read through the spec and to make adjustments. + +**Manu Sporny:** Scanning the entire document. Only non-normative section is the introduction. Everything else normative until security and privacy considerations. Believes that issue is not correct. +… Disagrees that there are more non-normative sections than other specs. Follows the pattern for others. +… Examples are supposed to be non-normative. Cursory review says everything is fine. + +**Brent Zundel:** Additional reviewers would be valuable. + +> *KevinDean:* On to 12. + +**Brent Zundel:** On to 12. + +#### 3.5. proofPurpose seems unnecessary in Controller Document spec (issue controller-document#12) +{: #section3-5} + +_See github issue [controller-document#12](https://github.com/w3c/controller-document/issues/12)._ + + + + + +**Brent Zundel:** Proof purpose seems unnecessary in controller document spec. Proof purpose wasn't in the original data integrity spec or JOSE-COSE spec. +… Is it possible that proof purpose was one of those properties where data integrity diverged from the controller document? + +**Manu Sporny:** Scanning the document. Proof purpose only shows up in three places, only in algorithm for creating the data integrity method. +… Needs to be rewritten so that proof purpose doesn't come from data integrity. + +#### 3.6. Make Conformance Classes a top-level section (issue controller-document#7) +{: #section3-6} + +_See github issue [controller-document#7](https://github.com/w3c/controller-document/issues/7)._ + + + + + +**Brent Zundel:** On to 7. +… Conformance classes appears too early in the document. Move to late in the document. +… We had a conversation about this last month. JOSE-COSE is the only document that does it this way, controller document more closely aligns with other documents produced. No agreement that this should be done. +… We don't have consensus that this issue should be addressed. + +**Manu Sporny:** Objects to moving this to somewhere else. In ReSpec, conformance section has boilerplate and top has "How to read this document". +… Standard boilerplate goes at the top of every W3C specification. Good for people to read that bit. +… Moving in document doesn't appear to make it better than what we have right now. +… Have this setup in multiple specifications, no object until now. + +**Brent Zundel:** On to 18. + +#### 3.7. Which document would (formally) define the terms for vocabularies (issue controller-document#18) +{: #section3-7} + +_See github issue [controller-document#18](https://github.com/w3c/controller-document/issues/18)._ + + + + + +**Brent Zundel:** Formal vocabulary terms for security terms in data integrity, move to controller document. + +**Manu Sporny:** Security vocabulary formally points to data integrity spec. Can update references to controller document. Would be the right thing to do. Can work with Ivan on that. + +**Brent Zundel:** Calling it a day. Still a number of issues that are open. +… Core data model in a good place, now focusing on controller document. + +--- diff --git a/assets/minute_processing.json b/assets/minute_processing.json index 17c530f..b1679c5 100644 --- a/assets/minute_processing.json +++ b/assets/minute_processing.json @@ -1,5 +1,5 @@ { - "date": "2024-06-12T16:05:59.814Z", + "date": "2024-06-19T17:33:49.305Z", "file_names": [ "2021-06-14-vcwg.md", "2021-08-11-vcwg.md", @@ -164,7 +164,8 @@ "2024-05-15-vcwg.md", "2024-05-29-vcwg.md", "2024-06-05-vcwg.md", - "2024-06-12-vcwg.md" + "2024-06-12-vcwg.md", + "2024-06-19-vcwg.md" ], "resolutions": [ { diff --git a/assets/nicknames.json b/assets/nicknames.json index 24dc51f..7c624a7 100644 --- a/assets/nicknames.json +++ b/assets/nicknames.json @@ -1343,5 +1343,12 @@ "anthony" ], "name": "Anthony Lopreiato" + }, + { + "nick": [ + "Guillermo", + "Melissa" + ], + "name": "Melissa Guillermo" } ]