14:30:46 RRSAgent has joined #vcwg 14:30:50 logging to https://www.w3.org/2023/10/18-vcwg-irc 14:30:50 RRSAgent, make logs Public 14:30:51 please title this meeting ("meeting: ..."), ivan 14:30:54 Meeting: Verifiable Credentials Working Group Telco 14:30:54 Date: 2023-10-18 14:30:54 Agenda: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231018T110000/ 14:30:54 chair: brent 14:30:54 ivan has changed the topic to: Meeting Agenda 2023-10-18: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231018T110000/ 14:36:33 brent has joined #vcwg 14:59:33 hsano has joined #vcwg 15:00:14 present+ 15:00:21 present+ 15:01:05 pdl-asu has joined #vcwg 15:01:15 present+ 15:01:16 present+ pauld, pl_asu, brent 15:01:47 present+ TallTed 15:02:14 pauld_gs1 has joined #vcwg 15:02:16 present+ 15:03:16 present+ dlongley 15:03:27 present+ 15:04:38 present+ orie 15:04:45 afk, for a min, as well brb 15:05:32 scribe+ 15:06:10 Orie has joined #vcwg 15:06:12 present+ 15:06:15 scribe+ 15:06:37 brent: Welcome everyone, let's get started. This is the VCWG regular call. 15:06:49 brent: We are going to be doing work item status updates, look at a few PRs, and rest of our time discussing issues. 15:07:45 brent: As mentioned during special topic call yesterday, the Chairs are going to be a bit more aggressive about declaring lack of consensus on PRs. If we do not have a clear path forward to consensus, the Chairs are going to strongly recommend closing PRs and that will lead to us re-examining underlying issues so group can determine whether or not those issues can be addressed in this iteration of the WG. 15:08:03 brent: We expect this might lead to some issues that people care about being marked as one that we cannot address and will need to be addressed by a future group. 15:08:19 brent: Any changes to agenda? 15:08:26 No changes to the agenda recommended. 15:08:29 Topic: Work Item status updates/PRs 15:08:38 q+ to provide updates on DI 15:08:54 brent: Updates on work items, PRs, core data model PRs? 15:08:57 present+ davidc, joe 15:08:58 ack manu 15:08:58 manu, you wanted to provide updates on DI 15:09:00 DavidC_ has joined #vcwg 15:09:02 present+ 15:09:08 manu: as discussed on special topic call 15:09:14 https://github.com/w3c/vc-data-integrity/pulls 15:09:18 ... there are 2 new PRs on vc-data-integrity 15:09:19 https://github.com/w3c/vc-data-integrity/pull/213 15:09:35 ... adds internationalization and commentary 15:09:36 https://github.com/w3c/vc-data-integrity/pull/214 15:09:45 ... clarified the details of the multibase data type 15:10:01 ... hoping for more reviews 15:10:14 ... plan to cut CR after these are merged 15:10:22 ... PRs will be merged by friday 15:11:07 ... all the data integrity specs have exist criteria, seeking implementations, etc. 15:11:25 q+ 15:11:31 ... by this friday we should have CR ready documents for all data integrity documents 15:11:36 ... I ran all the checks 15:11:43 brent: Thanks for the update. 15:11:50 ack ivan 15:12:09 ivan: This was not the final review for CR, this was the first CR review -- knowing PLH and Yves, there might be more comments. 15:12:41 brent: The accelerated timeline, please review these PRs so we can merge them by Friday. 15:12:51 q+ 15:12:54 q+ 15:12:55 brent: I don't see Gabe on -- any updates for vc-json-schema? 15:12:57 ack ivan 15:13:07 q- 15:13:35 See this PR: https://github.com/w3c/vc-json-schema/pull/220 15:13:35 ivan: I saw PRs from Gabe, same level as other CR documents that Manu talked about... exit criteria is in status section, we'll wait for some feedback from i18n before it can continue... essentially on same level as Data Integrity specs. 15:14:06 brent: Please review the PR, we want to merge sooner than 1 week window so vc-json-schema can be ready for CR. 15:14:12 brent: Any updates for other work items? 15:14:13 q+ 15:14:21 ack manu 15:14:42 q+ 15:15:58 q? 15:17:12 manu: The renaming for the status list spec will happen by the end of this weekend. 15:17:23 a stupor manu 15:17:37 manu: We need to do a manual publication after that. 15:17:39 GregB has joined #vcwg 15:17:44 present+ 15:18:09 manu: I will prioritize vc-data-model first, then status list. 15:18:25 Sorry I'm late. We were presenting BBS work to NIST crypto club. 15:18:37 manu: Also, for BBS, Greg and I will help edit, not many changes from ecdsa-sd, so we'll try that direction to see how things go. 15:18:46 ack Orie 15:19:53 Orie: Been thinking about multiple status list details and wanted to ask, multistatus list representation stuff, is that going to block us, is it ready to go? I know MikeP was most interested in that work. I'm not sure if it is going to hold stuff back. Does anyone have context/awareness about scenario w/ multiple statuses or single list? Is it progressing? Do we cut it to publish document? Possibly longer conversation. 15:19:53 q+ 15:19:57 ack manu 15:20:12 manu: I spoke to Mike 15:20:31 ... I promised we would keep the multistatus list stuff in the spec 15:20:34 ... we can put the at risk marker in on it 15:20:47 ... if we don't see implementations, we'll cut it from the spec 15:21:02 ... there seems to be enough there that we could remove it if we need to 15:21:15 ... mike said he has implementations, we'll find out in CR 15:21:35 ... I share Orie's concerns, but it seems structured ok as is 15:21:57 ... we seem to be ok to remove it, if necessary 15:22:09 ... ecdsa-sd is also marked as "at risk" and could be removed 15:22:28 q+ 15:22:32 brent: Any other updates on work items? I think we have updates from all of them except vc-jose-cose. 15:22:35 ack Orie 15:23:46 Orie: There is currently no open PRs for vc-jose-cose -- we wanted to work with keys / controller documents. There is an open issue wrt. controller documents - how do we specify it? Separate spec? We'd like to cite a document, any other changes that have happened since we last discussed? In general, key identifiers and controller documents are blocking spec from progressing. 15:23:48 q+ 15:23:56 ack manu 15:24:05 many: we could unblock by 15:24:32 ... if the data integrity transitions happens on november 7th, we could cite the data integrity section as being in CR 15:24:56 ... we could decide to split the spec up, and publish the controller document bit out as a separate document 15:25:10 ... as long as the content is the same, the document can start out in the candidate recommendation phase 15:25:26 ... then people can just cite the data integrity spec defined controlled documebnt 15:25:28 q+ 15:25:37 q+ 15:25:39 ... no normative changes would be made 15:25:47 ... thats one approach we could take 15:25:54 ack Orie 15:26:04 q+ Orie 15:26:07 ack ivan 15:26:30 ivan: I am not sure whether that's doable or not, I have never met this kind of problem before. If we really want to do this, we have to write this down and ask PLH... I cannot say yes/no right now. 15:26:41 ivan: Brent, any thoughts? 15:27:08 brent: My read of the process doesn't really touch on this... the process doesn't say we can't. It also doesn't explicitly say "that's fine" -- this is an edge case that's not in the process document. 15:27:21 brent: We'd have to write down our intentions and get an OK from Philippe. 15:27:25 ack Orie 15:27:53 Orie: I'm glad that this path is on the table, my understanding is that this path was always on the table. We could have decided to do this before sending DI to CR, we could make changes before CR -- then we don't have extra process question. 15:27:55 q+ 15:28:16 Orie: Open question, can we just publish a different document? 15:28:59 Orie: Citing Data Integrity of controller documents w/o making normative changes is unlikely to satisfy a neutral shared interpretation of controller documents. When I adjusted the controller document language, there were DI details there, also ZCAP, encryption, etc... not specific to VCs, but are present in the document. 15:29:21 Orie: I'm not sure if we did take splitting at CR approach that that would work. I'm happy to help however I can, mostly just looking for options, appreciate that this is one option. 15:29:24 ack ivan 15:30:13 ivan: Answering one question Orie had, might answer what Manu said. Yes, at any time, we have right to reorganize our deliverables -- we can merge documents, split documents, we have the right to do so. No problem there. The only problem is that if there is a new document, then what is its status? Is it a WD, CR, or something else? 15:30:40 ivan: The problem is that this is related to patent policy, if you have a new document which hasn't been around before, even if it is a part of something, starts a new patent policy cycle... usually done when you do a FPWD. 15:31:11 ivan: That's why FPWD is such an important step, if we take out this part from CR, then it has to go to FPWD to start the patent policy process even if what we can do, after six weeks, we go to CR right away. 15:31:16 ivan: I suspect that's the case. 15:31:32 My preference would be to introduce the controller document as a new document, FPWD, and clean up the content before trying to send it to CR. 15:31:48 brent: With that interpretation of process, alongside Orie's concerns that normative changes might be required, it sounds like even if we pull that section out during CR, the stuff we pull out would have to start out as a FPWD. 15:32:04 brent: That would give us opportunity to do patent review and normative changes. 15:32:05 q+ 15:32:12 brent: As a path forward, how do folks feel about that? 15:32:23 manu: I'm ok w/ that as a path forward ... -1 for taking that section out now. 15:32:26 q+ 15:32:30 ack ivan 15:32:45 I agree with Ivan and Brent. 15:33:12 ivan: Brent, it seems like we have a mind meld going on. I wanted to ask same thing... cleanest thing if we go that way is to take that part out now, that's what we would go into CR with. That would mean we have to do FPWD of that document, quick, could publish almost at same time as CR for other documents. 15:33:18 ack manu 15:33:30 manu: I am a -1 to holding up data integrity yet again 15:34:03 -1 to hold up DI, +1 to issue marker to decouple 15:34:04 ... instead we could allow data integrity to go forward, and add a market that it would be replaced by another document that would not change the controller document 15:34:28 ... normative changes might not get consensus, and that would then prevent the documents from advancing 15:35:12 ... I would be a -1 to jepardizing CR for data integrity... I prefer to put a marker, that says the WG is working on a controller document, and data integrity might refer to that spec in the future 15:35:23 ... the only difference here is that it decouples things 15:35:37 brent: Nothing you said is incompatible with what I was suggesting, I think we're aligned. 15:36:10 q+ to comment on the consensus of the data integrity controller document 15:36:21 +1 to an issue marker saying the controller document section might have a new reference with the same normative statements (or some subset of them having moved, some others specific to data integrity remaining in the DI spec) based on a new controller document being based on the DI spec 15:36:43 ivan: That seems fine, there might be some eyebrows raised. To play devils' advocate, removing one section from VCDI by itself is a quick thing to do. 15:36:52 ivan: I don't see that as jeopardizing the CR, you can do it in no time. 15:36:52 q+ 15:37:01 q+ to note this is a complicated set of changes. 15:37:15 ivan: How much time should we take to go through editorial trouble to turn it into a proper document. 15:37:34 ivan: We are preparing final version of CR now, by this weekend, this may be doable. I don't know, not an editor of the document. 15:37:41 ack Orie 15:37:42 Orie, you wanted to comment on the consensus of the data integrity controller document 15:38:09 JoeAndrieu has joined #vcwg 15:38:59 the current controller document consensus is based on it being in the data integrity spec, moving it could unsettle that in some unforeseen way. 15:38:59 ack manu 15:38:59 manu, you wanted to note this is a complicated set of changes. 15:38:59 Orie: I guess cutting into the meat of Manu's comment, the assertion is that the WG might not come to consensus of controller document, and current version of controller document becomes TR, then controller document as defined in DI has same normative changes that WG couldn't come to consensus on. It's possible that current document doesn't reflect WG consensus, we've been following process, there is a difference here in terms of consensus -- agree with 15:39:00 consensus comment Manu is making, if it's a concern, better to tackle it head on because it'll turn into an issue later. 15:39:04 q+ 15:39:32 ping ... scribe for manu? 15:40:25 manu: ivan, i think its more complicated that just removing the section 15:40:33 ... that would break references 15:40:45 ... we would need to update those references to a new location 15:40:59 ... we would need to address the FPWD side of the new document 15:41:07 ... it would take much time to do this 15:41:23 ... this would also have to be balanced against the core data model and status list PRs 15:41:39 ... so, its seeming like not something we should rush 15:41:55 ... lets not extract the section from the document, for now, lets just duplicate the content 15:42:04 I understand, Manu 15:42:06 ... and try to reconcile the content in the future 15:42:37 +1 to Manu 15:42:37 ... lets proceed with the plan 15:42:37 ack brent 15:43:06 brent: I want to note that the controller document section of DI has consensus as it pertains to DI. I'm not concerned about group consensus of that section. I agree that extracting it is more complicated. 15:43:31 I agree with Manu, I think this is probably the best path forward 15:43:33 +1 to Brent 15:44:05 q+ 15:44:10 brent: My recommendation as a path forward is: Let's add issue markers to that section in DI so that can move forward. In meantime, we can publish a FPWD of a controller document, that should be minimal, goal of that spec is to define general document that vc-jose-cose draw from, if that spec is successful, then changes indicated in DI can be acted upon and vc-jose-cose can point to the new controller document spec. Does anyone disagree with that path 15:44:10 forward? 15:44:10 ack ivan 15:44:13 +1 on "Data Controller Document Spec " : ) 15:44:26 ivan: First of all, I accept Manu's argument. 15:45:12 vc-jose-cose already has a section, we should add a similar marker to it... https://w3c.github.io/vc-jose-cose/#controller-documents 15:45:17 ivan: My understanding, what Manu is proposing is slightly different from what Brent is saying, vc-jose-cose could have similar section, along the lines of what they want to have there, and so issue statement that we would do -- good to have formalization for it -- another document produced by the group has a similar section and WG is considering merging those two approaches into one independent document. 15:45:44 +1 to say we're trying to create a separate document with the pieces that are in common 15:45:50 to allow common reference. 15:45:59 ivan: To make the message clear, we have two versions of similar concepts and we're trying to see if we can merge them into one separate document, or something of that sort. Not say "we're planning to take it into a separate document", but "we're trying to align between two specifications" 15:46:05 +1 dlongley's comment 15:46:17 manu: agree with the proposed course of action. 15:46:20 +1 15:46:27 +1 to this plan 15:46:29 brent: Anyone opposed to this course of action? If not, we're going to proceed. 15:46:37 No opposition to the plan. 15:46:41 Topic: Issue Discussion 15:46:50 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+-label%3A%22pr+exists%22+-label%3A%22ready+for+PR%22+ 15:47:17 pauld_gs1 has joined #vcwg 15:48:04 subtopic: https://github.com/w3c/vc-data-model/issues/1267 15:48:27 brent: This doesn't have an assignee, came up during privacy review. 15:48:46 manu: I can take this PR. 15:49:35 I suggest we not do a PR for that, and instead close the issue. 15:49:42 manu: 2-3 weeks, someone else do a PR before I get to it. 15:49:45 q+ 15:49:50 could mark it after / during CR too instead. 15:50:02 ack manu 15:50:14 manu: This came from security/privacy review... it might be bad to just close it since it came from horizontal review. 15:50:29 brent: Yes, we could ignore it, but neither of those options are the way things ought to be done. 15:50:38 brent: Thanks for volunteering, manu. 15:50:40 subtopic: https://github.com/w3c/vc-data-model/issues/1263 15:50:55 q+ 15:51:02 ack ivan 15:51:08 brent: What's the status of this? 15:51:25 ivan: This turned messy since end of August, including new versions of vocabulary/diagrams, which have been merged. 15:52:06 ivan: My proposal would be to close this issue because it's become unmanageable. Someone should take up responsibility of looking at spec and vocab and answer the original question, is domain/range correct yes/no, or if there are changes needed? 15:52:19 brent: not sure I agree w/ proposal to close issue. 15:52:31 ivan: There are some issues there / discussion, that have been put into changes. 15:52:46 ivan: That's difficult to follow. Diagrams have been updated, vocabularies have been updated. 15:52:57 brent: We would open a new issue to make sure domain/range matches what's in the data model? 15:53:09 brent: TallTed, this is your issue, would you be opposed to that course of action? 15:53:20 Is there a link to the diagram that landed? I feel the diagram in the issue is helpful 15:53:35 q+ 15:53:36 TallTed: I would not be opposed to a new issue that doesn't have the history, don't know how beneficial? Opposed to closing. We need a tracking issue. 15:53:39 +1 TallTed 15:53:43 ack ivan 15:53:46 brent: Agree, this is something that needs to be completed. 15:53:53 ivan: What I proposed is what Ted proposed. 15:54:00 +1 to open this issue fresh 15:54:03 ivan: Create a new issue to check domain/range. 15:54:11 brent: Ivan, can you open the new issue? 15:54:27 ivan: Yes. 15:54:44 subtopic: https://github.com/w3c/vc-data-model/issues/1155 15:55:10 q+ 15:55:16 brent: This issue tracks that i18n review happened. We had a meeting w/ i18n folks. 15:55:18 ack ivan 15:55:33 ivan: I think there is still a PR coming wrt. i18n issues in the document. The setting of default language/direction. 15:55:34 q+ 15:55:47 ivan: That should be put into a PR and eventually merged, when that's done, we can close this. 15:55:49 ack manu 15:56:07 manu: we are tracking that issue, seperatly 15:56:08 +1 ivan 15:56:17 ... I don't recall when we can close horizontal review issues 15:56:33 ... review happened, other issues were created, i think we can close this 15:56:47 ... the items they raised are tracked in other issues 15:56:58 brent: Thanks, that's my understanding as well. I'm going to close this issue after minutes are generated. 15:57:03 q+ 15:57:26 Just a note that there are 4 "applicable" items in the internationalization review. 15:57:27 brent: Ok, end of call, thanks everyone. 15:57:44 rrsagent, draft minutes 15:57:46 I have made the request to generate https://www.w3.org/2023/10/18-vcwg-minutes.html ivan 15:58:00 brent: Reminder that the chairs are going to become considerably more aggressive determining when we don't have consensus on PRs. Our timeline is overdue. 15:58:14 rrsagent, draft minutes 15:58:15 I have made the request to generate https://www.w3.org/2023/10/18-vcwg-minutes.html manu 15:58:53 zakim, end meeting 15:58:53 As of this point the attendees have been hsano, ivan, pdl-asu, pauld, pl_asu, brent, TallTed, pauld_gs, dlongley, manu, orie, davidc, joe, DavidC_, GregB 15:58:53 RRSAgent, please draft minutes 15:58:54 I have made the request to generate https://www.w3.org/2023/10/18-vcwg-minutes.html Zakim 15:59:00 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 15:59:00 Zakim has left #vcwg 15:59:12 gkellogg has joined #vcwg 15:59:35 rrsagent, bye 15:59:35 I see no action items