14:38:07 RRSAgent has joined #vcwg 14:38:11 logging to https://www.w3.org/2025/04/23-vcwg-irc 14:38:11 RRSAgent, make logs Public 14:38:12 please title this meeting ("meeting: ..."), ivan 14:38:14 Meeting: Verifiable Credentials Working Group Telco 14:38:14 Date: 2025-04-23 14:38:14 Agenda: https://www.w3.org/events/meetings/d03d7ee5-c761-4c67-825e-b483138033c7/20250423T110000/#agenda 14:38:14 chair: brent 14:38:15 ivan has changed the topic to: Meeting Agenda 2025-04-23: https://www.w3.org/events/meetings/d03d7ee5-c761-4c67-825e-b483138033c7/20250423T110000/#agenda 15:00:35 brent has joined #vcwg 15:00:41 present+ 15:00:52 present+ 15:00:54 JoeAndrieu has joined #vcwg 15:01:05 KevinDean has joined #vcwg 15:01:05 present+ brent, kevin, bigbluehat, joe 15:01:14 present+ 15:01:22 bigbluehat has joined #vcwg 15:01:30 present+ 15:01:31 present+ 15:01:33 present+ 15:01:41 hsano has joined #vcwg 15:01:48 present+ davidc 15:01:58 present+ davidc 15:02:09 present+ manu, hsano 15:02:13 DavidC has joined #vcwg 15:02:20 present+ 15:03:20 present+ dlongley 15:03:26 scribe+ 15:03:37 scrib+ 15:03:41 scribe+ 15:03:54 present+ selfissued 15:04:13 brent: Let's get started -- today we have our agenda, talk through next steps for REC, press release, security reviews, decision on meeting cadence moving forward. Any additional items to cover today? 15:04:31 selfissued: Fix to VC JOSE COSE? 15:04:50 Topic: Recommendation next steps 15:05:13 present+ 15:05:14 brent: We have a set of comments that were made as a part of the AC review during Proposed Rec, process requires us to have a response to the comments. 15:05:19 present+ TallTed, jennie 15:05:30 brent: The plan for the next bit is to share the comments and indicate what the response is planned to be to make sure we're on the same page. 15:05:39 q+ 15:06:10 ack ivan 15:06:24 JennieM has joined #vcwg 15:06:32 present+ 15:07:24 pdl-asu has joined #vcwg 15:07:29 ivan: As a general rule, we should know that (in theory) we're not supposed to change the specifications beyond the administrative items beyond PR and REC, except when it's explicitly asked for by a commenter. For those cases, it's better to postpone changes to the next minor release than make changes. If we make changes on the documents, we have to go back to the AC to ask for a second approval on changes to be made. We have to go back to AC reps to see 15:07:29 if it would change their vote, we would prefer to not do that at this point. 15:07:33 present+ 15:07:43 "§5.11 Ecosystem Compatibility should explicitly list SD-JWT and SD-JWT-VC to paragraph 1 which lists digital credential formats that do not natively use the VCDM. SD-JWT-VC even explicitly specifies it does not use the VCDM v1.0, v1.1, or v2.0. As SD-JWT(-VC) is a popular VC format for eIDAS it should be explicitly stated like the others." 15:07:43 [comment source](https://lists.w3.org/Archives/Member/w3c-archive/2025Apr/0606.html) 15:07:45 brent: For each of these comments, I will provide text and link to source of comment. 15:08:32 https://github.com/w3c/vc-data-model/issues/1593 15:08:39 present+ dmitriz 15:08:42 q+ 15:08:50 brent: comment on VCDM, text suggests say we list SD-JWT-VC to the ecosystem compatability section. The suggested response will be that we plan to address comment in future version of specification. 15:08:52 ack ivan 15:08:56 selfissued has joined #vcwg 15:09:04 ivan: Any response we make is better to send via email. 15:09:06 brent: I will do that. 15:09:09 present+ 15:09:12 q+ 15:09:22 ack KevinDean 15:09:25 ack KevinDean 15:09:35 KevinDean: Is there something we can add to the response to provide reasoning? Out of scope for current scope of work? 15:09:56 brent: This is an editorial change, we can address it under our current charter, seeing how ideally we shouldn't change text of REC, we can address this later. 15:09:58 q+ 15:10:00 q- 15:10:11 selfissued: That's fine. 15:10:40 subtopic: Data Integrity comments 15:11:13 "In our opinion, one of the lessons learned from XML Signatures was that complex canonicalization tied to a signature mechanism tends to lead to complex implementations and a higher likelihood of security vulnerabilities. Those lessons learned lead to the design of simpler signature mechanisms like those in JWT/CWT to avoid the complexity of canonicalization at least when doing cryptographic operations. We understand the general appeal of the ideas 15:11:13 behind Data Integrity Proofs but fear that it will lead to overly complex and insecure implementations by forcing implementations to perform rather complex RDF Dataset Canonicalization before any basic signature operation (sign, prove, verify) as is the case for some of the DI Cryptosuites, e.g., the ECDSA one. Semantics and signature mechanisms should be in their own respective layers to facilitate robust and secure implementations." 15:11:14 [comment source](https://lists.w3.org/Archives/Member/w3c-ac-forum/2025AprJun/0020.html) 15:11:20 brent: One comment on data integrity made by Torsten of SPRIND, they do not support the specification but are not formally objecting. 15:11:36 brent: This should be familiar to everyone in the meeting, we had long conversations about this as we were developing data integrity. 15:11:37 q+ 15:13:29 brent: At this point it's probably appropriate to note that while RDFC is more complex, JCS is also possible, there is the option to use JWS and CWS, we can point them to issue 272 where the group discussed this extenstively. 15:13:30 q- 15:14:06 subtopic: VC JOSE COSE 15:14:09 JennieM has joined #vcwg 15:14:19 "Since it is not a normative portion in this specification, it may not be a particular issue to change, but I would like to confirm one thing for the correctness of spec before publishing. I understand that all examples of COSE Sign1 within the CR (for example, EX-7) are protected by ES384. However, it appears that the signature is only 64 bytes, rather than the typical 96 bytes for P-384 signature. I am not an expert in COSE, so if such pruning or bit 15:14:19 truncation is correct in the viewpoint of COSE, there should be no problem." 15:14:19 [comment source](https://lists.w3.org/Archives/Member/w3c-archive/2025Apr/0444.html) 15:14:50 brent: We have two comments, both suggest publication... one comment is about COSE examples being incorrect -- we have fixed this issue. 15:14:50 q+ 15:15:03 ack ivan 15:15:05 q+ 15:15:18 ivan: This is waiting in a PR, correct? 15:15:26 https://github.com/w3c/vc-jose-cose/pull/341 15:15:34 q- 15:15:44 brent: We plan to merge that PR after the call today. 15:16:07 "The way this specification utilizes SD-JWT is sub-optimal as it double base64 encodes credentials in order to present them and it is more complex than needed as it uses SD-JWT as container for the presentation where there is no need for the SD-JWT capabilities." 15:16:07 [comment source](https://lists.w3.org/Archives/Member/w3c-ac-forum/2025AprJun/0020.html) 15:16:43 https://github.com/w3c/vc-jose-cose/issues/340 15:17:15 q+ 15:17:30 ack ivan 15:17:31 brent: We could respond by pointing to issue 340, there is a point here, closer examination on SD-JWT interacts w/ VCDM and presentations, we could explore this further. At this point, we plan to address this in future versions of the specification. 15:18:05 ivan: In the previous case, future versions are editorial... any change for this case is normative, not chartered to make this change (class 4). "Future version" would be next major version. 15:18:32 selfissued: We will consider addressing this concern, consensus might not result in a change. 15:18:49 brent: Any other comments on VC JOSE COSE before we move on? 15:19:30 subtopic: CID 15:19:39 brent: We had a number of comments on this one. 15:19:44 "Too similar to the code did specification. I wish it were presented as a clear extension of the did core specification that was clear about what’s different" 15:19:44 [comment source](https://lists.w3.org/Archives/Member/w3c-archive/2025Apr/0401.html), [answered by team contact](https://lists.w3.org/Archives/Team/team-vc-review/2025Apr/0009.html) 15:19:46 selfissued: I registered the media type. 15:20:08 brent: Ivan has responded to this comment, it is a superset of DIDs. 15:20:09 "§1 Introduction should note why the CID specification is necessary as those with less experience might see it as a recommendation over Decentralized Identifiers (DIDs) v1.0 rather than providing an abstraction to further make the case of DIDs." 15:20:09 [comment source](https://lists.w3.org/Archives/Member/w3c-archive/2025Apr/0606.html) 15:20:31 brent: They've asked for justification of the technology. 15:20:32 https://github.com/w3c/cid/issues/154 15:20:46 q+ 15:20:59 brent: We thank the commenter, we will try to address the concern in a future version of the specification. 15:21:05 dmitriz has joined #vcwg 15:21:10 q+ 15:21:13 present+ 15:21:26 ivan: Can we make a minor change to address this issue? 15:21:29 ack ivan 15:21:31 ack manu 15:22:12 manu: We should take our time to pick wording that's not controversial. 15:22:17 brent: Agree with that approach. 15:22:18 "As stated in the Revision History section, this specification was created "to use non-decentralized identifiers and systems". Those are already inclusively supported in DIDs, which chose a federated approach. If the editors wish to propose any other reason for this specification's existence, they should add a Motivation section in the Introduction explaining the reason." 15:22:18 [comment source](https://lists.w3.org/Archives/Member/w3c-archive/2025Apr/0579.html) 15:23:04 https://github.com/w3c/cid/issues/155 15:23:19 brent: The commenter here has pointed out that DIDs support this already -- we should add a motivation section. This is similar to the previous comment, but again, we should take our time to address this in the next version of the spec to make sure we pick language carefully. 15:23:39 brent: Any other comments on this one? 15:24:01 subtopic: BSL 15:24:03 q+ 15:25:01 ack ivan 15:25:09 brent: First comment is about usefulness, but privacy section is useful. We don't need to respond to this because there are no changes requested. 15:25:14 "§2 Data Model has a table that is not titled/labeled. Additionally, it should consider the factor of a scheme that proves status without revealing correlatable global identifiers. The authors do indirectly acknowledge this later in §6 but it is a very desirable trait and should be mentioned upfront in the overview. §6 Privacy Considerations should also discuss the ability/inability of using Zero-knowledge proofs for proving status." 15:25:14 [comment source](https://lists.w3.org/Archives/Member/w3c-archive/2025Apr/0606.html) 15:25:27 https://github.com/w3c/vc-bitstring-status-list/issues/204 15:25:31 brent: There is a table without a title, raised issue 204 to track that. 15:26:20 brent: The second comment was about ZKPs and anti-correlation and if we could figure out a way to do this using a ZKPs. 15:26:29 https://github.com/w3c/vc-bitstring-status-list/issues/203 15:27:01 q+ 15:27:01 brent: proposed response is to acknowledge that this would be useful and we will continue to explore this in a future version of the spec. 15:27:06 ack ivan 15:27:26 ivan: can we add the title and get rid of issue 204? 15:27:26 manu: yes 15:27:37 brent: I will convey that to the commenter. 15:27:52 q+ 15:27:57 ack ivan 15:28:08 brent: I think we have actions for manu, mike, and me -- we'll get those items done. 15:28:16 ivan: We need a date for the final version -- what is it going to be? 15:28:50 ivan: Manu, before you create final versions, final redirections need to be in place, right? 15:28:52 q+ 15:29:02 ack manu 15:29:14 manu: yes. put the final redirections in place 15:29:23 ... hopefully the hashes won't change 15:29:27 ivan: there's a new line feed 15:29:31 manu: k. 15:29:46 ivan: it will be done by the end of the week 15:29:52 q+ 15:30:04 ack manu 15:30:23 manu: for the date: May 15th? May 22nd? 15:30:31 ivan: how much time do you need to make the final versions? 15:30:35 manu: a weekend? maybe? 15:30:44 ivan: so, we could get the transition request in on the 2nd 15:30:54 ... they'll likely take some time, so the 15th is a safe bet 15:31:01 ... let's start with May 15th 15:31:10 q+ 15:31:12 brent: ok, anything else on recommendation next steps before we move on? 15:31:12 brent: anything more on recommendations next steps topic? 15:31:22 Topic: Press Release 15:31:27 ack ivan 15:32:26 ivan: I talked to Coralie, gave her all the material that the press release might have in it -- overview, slides, etc. She will pick that up and make a first version of press release. Thought maybe 15th for press release, that's it. 15:32:27 q+ 15:32:32 ack manu 15:32:40 manu: usually there are testimonials 15:32:49 ... are you looking for those too? 15:32:52 manu: usually there are testimonials -- are we looking for that? 15:33:07 ivan: Yes, we usually ask the group members for testimonials -- let's try to collect them in one place. 15:33:56 q+ 15:34:04 ack manu 15:35:11 manu: Why don't we cast a wide net, asking WG members, CCG members, etc? 15:35:35 ivan: Let's start with WG Members first, just personal opinion. I would hope several testimonials in from WG Members. 15:36:00 https://docs.google.com/document/d/1Iyd69-6aI0k3O79c8lAvc3FR6cVpYkWepNR39fVCooU/edit?usp=sharing 15:36:29 brent: There is the Google doc, shared to member mailing list to invite people to add things and then pass things on to Coralie -- we need these within a week. 15:36:50 Topic: Security Reviews 15:37:07 q+ 15:37:16 brent: Good news is we got security reviews... timing wise, they came in during Proposed Rec. 15:38:03 q- 15:38:42 brent: If you look in VCDI, ecdsa, plan with these is to take these issues as we take issues with maintenance mode, whether issue can be addressed non-normatively, or in security (if there is a vuln that needs to be addressed), do the triage as a part of our normal process moving forward. That's the plan as I see it -- happy to take comments on proceeding differently. We are grateful that they came in, but will be processing based on our maintenance 15:38:42 charter. 15:38:49 +1 15:38:53 manu: +1 to the proposed approach, fwiw. 15:39:16 Topic: Meeting Cadence moving forward 15:39:18 q+ 15:39:27 q+ 15:39:34 brent: would love to hear proposals on how often we should meet. 15:39:38 ack manu 15:39:39 brent: We can always change the cadence. 15:39:53 manu: we should meet at least once a month for maintenance items 15:40:05 ... the other thing happening now is the CCG work item promotion call 15:40:16 ... happens at the same time as this call -- while we were on our break 15:40:31 ... we're discussing things like Confidence Method, Render Method, VC API, etc. 15:40:43 ... some of those are already in our charter, others are not yet. 15:40:56 ... a few of those need a couple more months to be ready to bring in 15:41:07 ... we could also choose to spend a bit more time on them in the CCG 15:41:26 ... the suggestion is that VCWG meet once a month, and the CCG meets more often to finish off those specs a bit more 15:41:35 ... just a proposal 15:41:38 ack ivan 15:42:26 ivan: Two things, I would propose we keep current timing until we publish RECs, let's not take a break now... maintenance, publish working notes, etc. 15:42:27 q+ 15:43:09 manu: my recollection was that we were chartered for at least Render Method and Confidence Method 15:43:39 ... I believe there's also a number of specs heading into production like Verifiable Credential Barcodes and the like 15:43:48 ... which are nearing production deployments 15:43:57 ... and official standardization hasn't even formally started 15:44:08 q+ 15:44:21 ... we've mostly been focused on maintaining things, but I think we need a pathway for what new work might be and how we charter for it 15:44:30 ack ivan 15:44:32 q+ 15:44:36 ... it's all stuff that's been in the CCG for awhile 15:44:40 https://www.w3.org/2024/10/vc-wg-charter.html 15:45:26 ivan: Unfortunately, that's not that simple -- scope of the charter says that we maintain, no class 4, security issues -- then there is a separate section that says non-normative documents -- test suites , presentation requests, storage sharing, etc... 15:45:33 q+ 15:45:54 ivan: You are referring to thing that are much heavier work -- new cryptosuites, for example. 15:45:57 ack manu 15:46:07 manu: right. I'm talking about changing the charter 15:46:17 ... I'm saying there's a small amount of work we can continue doing 15:46:24 ... Confidence Method and Render Method 15:46:32 ... but that we also have new work for which we should recharter 15:46:40 ivan: ah. that wasn't clear earlier 15:46:41 ack brent 15:47:24 q+ 15:47:26 brent: One nuance to this -- even for render method and confidence method, our current charter allows us to add those sections and add normative language in that sections in VCDM spec, but scope says "no new RECs" are planned. We could put stuff in VCDM, but not new Render Method spec. 15:47:27 q+ 15:47:33 ack JoeAndrieu 15:47:33 brent: Something to be aware of. 15:47:53 JoeAndrieu: I think Ivan mentioned that as long as work is chartered, we can put it in other specs -- we might be able to create separate document. 15:48:06 ivan: Scope in charter specifically says "in VCDM" 15:48:11 ack manu 15:48:56 q+ 15:49:23 ack brent 15:49:36 manu: my fear is that we'd do a short term thing, with long term negative consequences 15:49:37 +1 that rechartering can also allow confidenceMethod/renderMethod to be moved to its own spec if the consensus is that current charter interpretation requires different organization 15:49:52 ... like stuffing Render Method content into the VCDM and then later needing to extract it 15:50:13 +1 to brent, we can do the rechartering when its time to reorganize and fold these things in with the other items we might take on. 15:50:28 brent: I'm bringing it up to inform the group that the charter language is explicit, maybe the group should recharter to more appropriately handle it. Our current charter can be rechartered before Oct 2026... I was remembering our charter as not being this constrained. When those things are ready to move on, maybe we have a serious conversation around rechartering. 15:51:26 brent: We will keep meeting until we get through REC -- once we get through May 15th, you should see a whole new invitation for a monthly meeting -- 2nd Wednesday of the month (to just pick something). That will work until we have more work than a monthly meeting will handle. 15:51:44 ivan: When should the responses go out? 15:51:52 brent: The aim is by the end of the week. 15:52:28 brent: Thanks everyone, good to be with everyone again, see you soon! 15:52:34 rrsagent, draft minutes 15:52:35 I have made the request to generate https://www.w3.org/2025/04/23-vcwg-minutes.html ivan 15:53:45 zakim, bye 15:53:45 leaving. As of this point the attendees have been ivan, brent, kevin, bigbluehat, joe, KevinDean, denkeni, JoeAndrieu, davidc, manu, hsano, dlongley, selfissued, TallTed, jennie, 15:53:45 Zakim has left #vcwg 15:53:48 ... JennieM, pdl-asu, dmitriz 15:53:51 rrsagent, bye 15:53:51 I see no action items