15:18:30 RRSAgent has joined #vcwg 15:18:34 logging to https://www.w3.org/2024/12/18-vcwg-irc 15:18:34 RRSAgent, make logs Public 15:18:35 please title this meeting ("meeting: ..."), ivan 15:18:36 Meeting: Verifiable Credentials Working Group Telco 15:18:36 Date: 2024-12-18 15:18:36 Agenda: https://www.w3.org/events/meetings/d03d7ee5-c761-4c67-825e-b483138033c7/20241218T110000// 15:18:36 chair: brent 15:18:37 ivan has changed the topic to: Meeting Agenda 2024-12-18: https://www.w3.org/events/meetings/d03d7ee5-c761-4c67-825e-b483138033c7/20241218T110000/ 15:54:57 mandyv8 has joined #vcwg 15:55:45 present+ 15:57:58 s|20241218T110000//|20241218T110000/ | 15:58:05 present+ dmitriz 15:58:24 brent has joined #vcwg 15:58:40 present+ brent 15:59:27 present+ 15:59:36 present+ mandyv 15:59:47 present+ TallTed 16:00:44 wes-smith has joined #vcwg 16:00:44 present+ wes-smith 16:01:08 present+ manu, davidc 16:01:29 DavidC has joined #vcwg 16:01:30 present+ denken 16:01:38 present+ 16:01:48 present+ dlongley 16:02:17 hsano has joined #vcwg 16:02:33 denkeni has joined #vcwg 16:02:45 present+ 16:03:07 present+ hsano, will 16:03:29 Wip has joined #vcwg 16:03:58 present+ PDL-ASU 16:04:11 present+ selfissued 16:04:11 phil_ASU has joined #vcwg 16:04:13 scribe+\ 16:04:15 scribe+ 16:04:16 selfissued has joined #vcwg 16:04:22 present+ 16:04:35 present+ 16:04:43 present+ jennie 16:04:46 Brent: welcome everybody to the 12/18 VCWG meeting, we will not be holding a meeting on 12/25 or 1/1, after today our next meeting will be 1/8 16:04:58 Sorry I was on mute when I said I'd be happy to scribe but I'll do the next time if needed. 16:05:03 ... our agenda today consists of talking through the Controlled Identifier Document, and as time permits the status list document 16:05:25 q+ 16:05:33 ack manu 16:05:57 manu: I would like to talk about where we are with the test suites and what is at risk of being removed from the specifications 16:06:05 present+ dlehn 16:06:12 Topic: Test Suites 16:06:16 q+ 16:06:20 ack manu 16:07:35 ... We're largely in good shape for VCDM 2.0, ECDSA/EDDSA cryptosuites, data integrity - the at-risk things for those specs are in progress with multiple implementers. For bitstring status list, of all the implementations that are currently in the test suite, and we have 7, none of them are implementing the variable size status mechanism. 16:08:02 q+ 16:08:21 ... That is at-risk, and if we don't have at least two independent implementations for that feature it will need to be removed from the spec. I don't know where we are with VC JOSE-COSE and VC JSON schema, and BBS won't be transitioned to rec in Q1 next year. 16:08:25 ack brent 16:09:08 q+ 16:09:20 q+ 16:09:24 Brent: I know that mesur is intending to show support for multiple status lists, VC JOSE-COSE test suite just got a major update by decentralgabe and should be ready to receive implementations, for JSON schema it's just a matter of getting the implementers to interface with the test suite 16:09:27 ack ivan 16:09:45 Ivan: Do we have new information about the normative status of SD-JWT? 16:10:29 selfissued: It has completed working group last call, there was a formal protest made by an individual, the area director responded, the editors incorporated the changes suggested by the area director, therefore it is probably within 1-2 weeks of the shepherd writeup and requested publication by the IETF. 16:11:03 q+ 16:11:14 ... That means it undergoes review then goes to a group of area directors, then to the RFC editor. This usually takes about 4 months. 16:11:18 q- later 16:11:19 ack ivan 16:12:19 Ivan: The idea is to go to proposed rec in the first half of Feb. SD-JWT must be recommendation level when we go to proposed rec for us to reference it. 16:13:27 ack manu 16:14:24 manu: If we don't have some of these at-risk things done or specs are not in the proper place it will delay our ability to get to proposed recommendation. The other risk is Controllable Identifier Document, the publication of that has been delayed indefinitely until we get reviews back. We can go to PR with that in CR, but ideally we have CID in PR 16:14:24 at the same time as the other documents. 16:14:32 selfissued has joined #vcwg 16:14:41 present+ 16:14:44 q+ 16:14:55 ack selfissued 16:15:30 Topic: CID 16:15:37 q+ 16:15:47 subtopic: https://github.com/w3c/cid/pull/120 16:15:49 Brent: looking at CID PR 120 16:15:55 ack selfissued 16:16:15 selfissued: I now have more context on why 120 was written in the first place. It was written as a result of issue 115. Issue 115 is a clear request to choose one key format. 16:16:36 ... now as I wrote in the issue, I realized there is not going to be WG consensus to remove either key format, that issue should be closed as "won't fix". 16:17:02 https://github.com/w3c/cid/issues/115 16:17:13 q+ 16:17:21 bigbluehat has joined #vcwg 16:17:24 ... Secondarily, PR 120 ironically would take the spec in the opposite direction as requested in the issue by sanctioning the use of additional key formats rather than choosing one. Therefore that should not be merged. My proposal is that only the key formats specified in the documents should be used, and if that language is used I would be OK 16:17:26 merging it. We should close them both on the call today. 16:17:31 ack manu 16:17:36 present+ 16:17:47 q+ 16:18:26 manu: disagree with the notion that the PR went in the opposite direction. The request was "do 1 key format". I agree that we aren't going to do that. As a result the PR was attempting to explain why we are not going to get to one key format. The PR tries to document why that is not realistic, I won't object to use saying we won't fix it and 16:18:27 closing it, but the spec would benefit from us explaining why we have made the decision we have made. 16:18:40 ... The reality is that there are more than one key format in use, it's an application specific choice. 16:18:55 ... If we can't get to agreement on writing that in the spec I'm fine with closing the PR and the issue. 16:18:59 ack selfissued 16:19:18 q+ 16:19:39 q- 16:19:42 selfissued: the problem with the PR is that it does two things - it explains why we don't have consensus on a single format, and it adds new language saying implementations should use key formats defined by the specification rather than must. That's a weakening of the normative requirements and I can't support that. We can close them both, it's the 16:19:42 best we're gonna do. 16:19:55 q+ 16:20:11 Brent: would anyone else in the group be opposed to closing PR 120 and issue 115? 16:20:12 ack selfissued 16:20:13 not opposed to closing, disagree that the spec isn't more open world already. 16:20:42 I am fine with closing both 16:20:55 q- 16:20:58 hsano has joined #vcwg 16:21:11 ... not hearing any objections, that is our path forward. The plan is to close PR 120 after the call today and close 115 after the call today with the minutes as an explanation for our reasoning. With that, let's look at the other PRs. 16:21:19 subtopic: https://github.com/w3c/cid/pull/126 16:21:49 ... PR 126, fix the definition of controller and add verification method binding section. There are changes requested. Let's talk about it. If your changes have been addressed please let us know. 16:22:06 q+ 16:22:11 ack manu 16:22:41 q+ 16:22:50 q+ 16:22:59 manu: I think this was just up to Joe and David to find the proper wording, I think we added wording to the specification, David's wording is slightly different, Joe is disagreeing with that new wording, I think that's where we are. If we can't get to consensus I suggest we close PR 126 and resolve that 119 is either done or won't fix based on 16:22:59 differing opinions. 16:23:04 ack selfissued 16:23:48 q+ 16:23:57 ack DavidC 16:23:59 selfissued: I had two change requests, one was not to take DavidC's wording change, which hasn't been taken, the other was that this PR did two things, fixed the definition of controller, which I support, but it also added a verification method binding section, which is not related to the purpose of the PR and is extra text that was not in the 16:23:59 specifications, I will support merging or closing this PR if that section is removed. 16:25:11 ack manu 16:25:15 DavidC: there was a disagreement because the controller of the verification method is in control of the verification method, but putting text to that effect was objected to by Joe because the verification method cannot be updated in that document. There is a possibility to allow these documents to sync. 16:26:07 manu: to selfissued, if we remove the thing you want to remove we are left with just a definition, this continued wordsmithing will go on around the definition of controller. I take DavidC's point, we are searching for language everyone can agree to, it might be easiest to use a new PR to do that. I'll note that the text Ivan wanted me to move over 16:26:07 would be removed. 16:26:10 q+ 16:26:24 ... we can close the PR and try again, and maybe DavidC can raise that PR and we can all look at it. 16:26:27 ack ivan 16:27:22 Ivan: if I understood what DavidC was saying, the problem is that we are all influenced by a particular way a verification method and controller document are used within this community where the verification method is part of the controller document. However, these two can be distinct documents linked by a URL. These settings are different, that is 16:27:22 one of the reasons there is disagreement, this is also my issue all along. 16:27:38 ... If the two are separated they need to be treated as such, that is not really done in the spec. 16:28:52 https://github.com/w3c/cid/pull/119 16:28:53 Brent: At this point, the suggestion before us is to close 126, and if there is still a desire to continue on tweaking language to address issue 119 a new PR must be raised. My suggestion is that after the call we close 126. If, by the time we return in January, there is not a new PR that will lead us to consensus, we will close 119. Is that 16:28:53 acceptable to folks? 16:28:54 I commit to producing a new PR for issue 119 16:28:56 +1 for the proposed plan forward. 16:29:13 +1 16:29:25 ... moving conversation to 131. 16:29:28 subtopic: https://github.com/w3c/cid/pull/131 16:29:34 q+ 16:29:41 ack manu 16:29:42 ... add SM2 algorithm support. Has a couple requests for changes. 16:30:16 manu: I put a change suggestion in there to see if the original person that raised the issue would have any objections. If they don't, we can merge it after. I'll remove the JSON web key expression and merge it after a day or two of waiting. 16:30:58 Brent: I believe the changes requested by TallTed have gone in. Path forward is the SM2 algorithm that's being added will be added for Data Integrity, on the JWK side it would be handled at IETF. 16:31:19 ... with that all concerns will have been addressed and the PR can be merged. If folks disagree with this plan please speak up, otherwise we will move to our final PR. 16:31:20 brentz has joined #vcwg 16:31:48 mandyv has joined #vcwg 16:32:00 subtopic: https://github.com/w3c/cid/pull/134 16:32:45 Thanks all. Gotta run now. 16:32:52 Ivan: there are a bunch of places where the controller document term was still used, and I changed them to the new name, nothing earthshaking. One thing which is there, for example, the old error message names are "Invalid Controller Document", and that kind of thing. 16:33:20 Brent: This sounds very straightforward, I encourage folks to review it if they like, I anticipate this PR will be merged by the end of the week. 16:33:54 q+ 16:34:09 ... With these decisions we will have addressed all the open PRs. We plan to close issue 115, and we are fully editorial with our remaining issues, even including trying to address 119, as that won't introduce normative language. 16:34:35 ... I believe that after the PRs are processed as we have discussed the document is in a stable place. If you disagree please speak up. With that we could entertain a proposal to move to CR. 16:34:41 ack manu 16:34:53 subtopic: CID as CR 16:35:12 manu: we have one normative item that jyasskin raised two days ago. We will state that we will define the fragment resolution algorithm in CR1, or we can wait until that is in to go to CR1. 16:35:36 q+ 16:35:50 ack ivan 16:35:51 Brent: the suggestion is that we propose to go to CR after adding language to the spec that we plan to make the single change of defining the fragment resolution algorithm. 16:36:09 q+ 16:36:30 Ivan: I am not opposed to doing a resolution today, but at the moment I cannot pick it up and raise an issue to do a transition request, because we have to get at least some answers from the horizontal reviews. I cannot act on a resolution before January. 16:36:37 ... there is no rush, unfortunately. 16:36:47 Brent: If we were to resolve today, would things be able to move before our meeting on 1/8? 16:36:53 q+ 16:37:07 Ivan: provided we get at least some horizontal review, and there is nothing to act on in the document as a result, that's possible. 16:37:13 Brent: Could resolving inhibit this progress? 16:37:16 Ivan: No 16:37:29 ack manu 16:37:29 Brent: Then there is some possibility of some small benefit of resolving now and no risk. 16:37:57 manu: On the horizontal review, Ivan the TAG has finished their review, so we are just waiting on security and accessibility. Just noting there are only 2 that have not been done. 16:38:06 ... We also need to pick a short name. 16:38:14 Ivan: We need to formally agree on the new short name. 16:38:24 Brent: Does anyone have draft language for a proposal? 16:40:16 Ivan: we should say as soon as possible rather than saying a specific date. 16:41:16 PROPOSAL: Publish the Controlled Identifier Document v1.0 specification as a First Candidate Recommendation (https://w3c.github.io/cid/transitions/2025/CR1/index.html) with a new short name of cid-1.0, a preferred publication date as soon as possible, and a CR period of one month. Two independent implementations of each mandatory normative feature are required to proceed this specification to the Proposed Recommendation phase. 16:41:23 +1 16:41:23 +1 16:41:23 +1 16:41:24 +1 16:41:24 +1 16:41:24 +1 16:41:25 +1 16:41:26 +1 16:41:27 +1 16:41:29 +1 16:41:57 q+ to talk about practicalities 16:42:05 RESOLVED: Publish the Controlled Identifier Document v1.0 specification as a First Candidate Recommendation (https://w3c.github.io/cid/transitions/2025/CR1/index.html) with a new short name of cid-1.0, a preferred publication date as soon as possible, and a CR period of one month. Two independent implementations of each mandatory normative feature are required to proceed this specification to the Proposed Recommendation phase. 16:42:09 ack ivan 16:42:09 ivan, you wanted to talk about practicalities 16:42:32 Ivan: Manu I prepared the transition request, a draft of it, as usual I would like you to look at it, mainly on the horizontal review section to make that precise. 16:42:34 manu: will do 16:42:35 q+ to note I also requested final HR reviews (next topic) 16:42:45 Brentz: final topic is status list. 16:42:55 ack manu 16:42:55 manu, you wanted to note I also requested final HR reviews (next topic) 16:43:03 manu: I want to quickly note to the group that I requested a final review of all 7 of the specs, just want to make sure the group knows. 16:43:06 Topic: Status List 16:43:08 for example: https://github.com/w3ctag/design-reviews/issues/1029 16:43:10 https://github.com/w3c/vc-bitstring-status-list/issues?q=is%3Aissue+is%3Aopen+label%3Anormative+sort%3Aupdated-asc 16:43:28 Brent: status list. Here is the link to the issues. There are 4 open issues on BSSL. 16:43:44 s/Brent/brentz 16:43:50 q+ 16:43:51 subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/173 16:44:20 Brentz: we are looking at issue 173. Add a MUST statement preventing two entries from having the same status purpose. 16:44:29 ack manu 16:44:29 ... We discussed this, I believe we decided we are not going to do this. 16:44:39 manu: Correct, should we mark this pending close, or should we just close it now? 16:45:03 Brentz: let's add the pending close tag and hopefully it will disappear over the break. 16:45:16 ... Next is 184 16:45:16 subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/184 16:45:17 q+ 16:45:53 q- 16:46:01 ... clarification on multiple items inside BSSL credential subject. We talked about this last week. The suggestion was to say clearly that the revocation bit applies to all the credential subjects, we don't differentiate between multiple credential subjects in a status entry. 16:46:30 ... I believe this should be a totally editorial change. Did Joe volunteer to raise a PR with some text? I think we are still awaiting that, I will ping Joe in the issue and we can move on unless folks have comments. 16:46:54 subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/194 16:47:00 q+ 16:47:17 ack manu 16:47:23 ... Next is 194, implementer feedback on multiple status entries in a single list. Pat St Louis wants that feature to remain. 16:48:24 manu: This is good input, it's enough for us to use this as a reason to not remove the feature. I don't think we need anything new in the test suite or the implementation report, you can do this today and we don't need new tests. The only change is to remove the at risk features and say we had an implementer that liked this and the other 16:48:24 implementations support it by default. 16:48:58 brentz: The response to this is now we can close the issue because we agree and we will not have to do anything other than make the change to the at risk notification, at which point we can close this. 16:49:25 ... The last issue is final horizontal review for BSSL, raised by manu and tracks the last horizontal reviews required before we go to PR. 16:49:49 ... I believe it is still the case that BSSL has not undergone normative/substantive changes after going into CR and so the next step is proposed rec. 16:50:40 q+ 16:50:53 ack ivan 16:50:56 ... With that we are expecting one more editorial PR on BSSL and then it's in a good spot. I think we're done for today, we have talked about everything we can and everything is in as good a place as it can be. There are a couple PRs we are hoping to see over the break, other than that we are ready to move forward when we get reviews. 16:51:17 Ivan: We have good chances that CR2 will be published tomorrow for VCDM 2.0, the cryptosuites, and JOSE-COSE 16:51:52 Brentz: As usual we anticipate some additional review/issues on these specs, this feedback is welcome and is the purpose of going into CR2. Happy holidays all, looking forward to seeing you in three weeks. 16:52:04 rrsagent, draft minutes 16:52:05 I have made the request to generate https://www.w3.org/2024/12/18-vcwg-minutes.html ivan 16:53:54 zakim, bye 16:53:54 leaving. As of this point the attendees have been ivan, dmitriz, brent, TallTed, mandyv, wes-smith, manu, davidc, denken, dlongley, denkeni, hsano, will, PDL-ASU, selfissued, 16:53:54 Zakim has left #vcwg 16:53:57 ... phil_ASU, jennie, dlehn, bigbluehat 16:53:59 rrsagent, bye 16:53:59 I see no action items