15:02:53 RRSAgent has joined #vcwg 15:02:58 logging to https://www.w3.org/2024/02/28-vcwg-irc 15:02:58 RRSAgent, make logs Public 15:02:59 please title this meeting ("meeting: ..."), ivan 15:03:27 Meeting: Verifiable Credentials Working Group Telco 15:03:27 Date: 2024-02-28 15:03:27 Agenda: https://www.w3.org/events/meetings/0d074559-1457-4540-857b-24b1be7a8d7f/20240228T110000/ 15:03:27 chair: brent 15:03:28 ivan has changed the topic to: Meeting Agenda 2024-02-28: https://www.w3.org/events/meetings/0d074559-1457-4540-857b-24b1be7a8d7f/20240228T110000/ 15:51:18 brent has joined #vcwg 15:57:34 present+ 15:58:39 present+ pauld_gs1 15:59:37 present+ 16:00:56 present+ dlongley 16:03:45 DavidC has joined #vcwg 16:03:56 present+ 16:04:07 present+ 16:04:34 present+ will 16:04:38 present+ TallTed 16:05:18 will has joined #vcwg 16:05:18 present+ 16:05:32 scribe+ 16:06:00 present+ manu 16:06:20 brent: We will look at work items, get status updates, highlight PRs that the editors want more review on, then jump into processing the VCDM issues. 16:06:29 brent: Anyone who would like to suggest changes or additions to the agenda? 16:06:31 present+ jandrieu 16:06:31 q+ 16:06:39 ack manu 16:06:57 JoeAndrieu has joined #vcwg 16:07:18 manu: Apologies -- a bit out of the blue. In the RCH WG, we just resolved to take that spec to PR. Part of that discussion was around what a maintenance WG would do around security specs. It may be a bit premature here, but we can mention what that group did and then think along those lines. 16:07:29 manu: So five minutes to explain what happened, that would be useful. 16:07:33 brent: Ok. 16:07:46 Topic: maintenance? 16:08:25 manu: Ivan, please correct me if I get this wrong. We said we were going to attempt to transition RDF-CANON to PR, we've kept the door open for a while and have plenty of implementations and feedback. 16:08:44 manu: One of the things mentioned was around what to do about possible future security issues. The proposal was to say that the spec allows "class 4" changes. 16:09:02 manu: Those changes could be applied during the maintenance period to address security vulnerabilities. 16:09:10 present+ bigbluehat 16:09:22 Jennie has joined #vcwg 16:09:25 manu: If we do that here as well, which I think is a good idea, then a maintenance WG can be responsive to fix any found security vulnerabilities. 16:09:35 present+ jennie 16:09:36 manu: The alternative is to not do that and then you can't update the spec even in the face of security vulnerabilities. 16:10:15 manu: As we transition these specs into PR... -- this group will propose a maintenance group charter and we should say that that group can and will fix any security vulnerabilities that come up. 16:10:18 manu: Hopefully that was a useful summary. 16:10:30 brent: Any comments? 16:10:38 brent: Thank you for that. 16:10:51 Topic: Work Item Status Updates/PRs 16:10:57 q+ 16:11:03 ack manu 16:11:51 manu: Updates on VC DI specs. I'm putting some focus on that to give the other editors and I ... we're trying to reduce all the issues down to zero. There are a mix of editorial and normative changes to be made, working towards a second CR. The major change was integrating Jeffrey Yaskin's interfaces into the DI specs. 16:12:00 manu: It didn't change implementations, just how things interrelated. 16:12:20 q+ 16:12:26 manu: We're behind on the BitstringStatusList stuff, some internationalization things to address there. 16:12:32 manu: There are some PRs there to look at. 16:13:13 manu: The W3C TAG has also completed their review of VCDM 2.0, the status list spec, and one other one ... and the general feedback was that the VCDM 2.0 was that they wouldn't take a position on polyglot, no consensus on that concept. 16:13:32 manu: There was a DI spec they mentioned, they said they were not taking a position on whether unlinkable signatures should be mandatory or not, but they'd like to hear more from PING. 16:14:00 manu: For BitstringStatusList, they raised some concerns and so did PING and we asked for them to raise issues on our tracker for things they really want addressed. Many issues we knww about and we just explained how we got to where we are. 16:14:39 manu: Some of the feedback was saying that it would be great to have even more privacy preserving mechanisms -- and that would be great, but we need to be rechartered to take that on and on top of that there are some concerns around NIST, EDSI accepting those sorts of things. 16:15:18 manu: That's an update on DI and status list -- there are PRs to be updated and merged, take a look. 16:15:32 manu: Many of the things left aren't very controversial, we just need to put our heads down and get them done. 16:15:37 ack brent 16:15:51 q+ 16:15:55 brent: I don't see Gabe or Mike Jones here -- I can report on VC-JOSE-COSE, they are down to seven issues triaged before CR. 16:16:06 brent: They are on a good track to get those done on a reasonable time frame. 16:16:37 brent: The group decision to reintroduce JWS has been accomplished and that PR was merged. The remaining issues are pretty straightforward, there are some that are a little trickier but overall things are proceeding well with it. 16:16:38 ack ivan 16:16:41 q+ 16:17:11 DavidC: A lot of the issues I raised and a PR raised as well ... but when the solutions were raised I didn't get a chance to comment on them. 16:17:21 bigbluehat has joined #vcwg 16:17:32 brent: The review window was at least a week and the PRs were discussed in this call, folks were given an opportunity to review, I haven't seen any procedural violations. 16:17:48 DavidC: I would just think as a matter of politeness folks would be asked to review on the PRs. 16:18:07 brent: Let the minutes show that the vc-jose-cose editors ping folks when they raise PRs to address their issues to come review those PRs. 16:18:21 ack DavidC 16:18:37 DavidC: Yes, I think that's good. I know Manu was always asking me to review even if I didn't ask for changes / make issues. 16:19:00 ivan: I was asked last week to reach out to the activity streams people on `mediaType` to try and reuse what they have. 16:19:17 present+ 16:19:27 ivan: I don't want to get into the details, it's not that exciting, the bottomline is that they don't have a process to change anything normative and the changes we wanted were normative. So we can't take that avenue. 16:19:51 ivan: In some sense, was that the original issue wasn't really of interest anymore and the person who raised it, Benjamin Goehring, said we can close that issue because it isn't relevant anymore. 16:19:53 q+ 16:19:57 ivan: I recommend we close the issue. 16:20:02 ack manu 16:20:29 manu: I want to agree with Ivan. I think we should probably do that. I have some trepidation where we haven't addressed the root cause or given them a way to use VCs and AS together. I'm concerned about leaving that there. 16:20:45 manu: I think they will be incompatible with each other, you can't put a VC in an AS thing. 16:21:09 manu: They said that you could if you used the "as:" prefix to differentiate. I don't know if that would actually survive expansion and recompaction. 16:21:25 manu: We should maybe provide some guidance somewhere on that. 16:21:49 manu: The other decision we need to make internally here -- is that you're saying we should switch to `encodingFormat`? 16:21:54 ivan: That was ruled out by the WG. 16:22:01 manu: That was because we were trying to work with AS. 16:22:01 -> AS Issue https://github.com/w3c/activitystreams/issues/584 16:22:36 -> Our relevant issue https://github.com/w3c/vc-data-model/issues/1408 16:22:37 manu: Evan, in AS, was annoyed that we would create something to conflict with AS -- the good reason is that it's important when you digitally sign things you know what you're signing -- and the software is doing the right thing to point out `mediaType` is being used in two different ways. 16:22:54 q+ 16:22:57 manu: We need to provide some kind of guidance here -- the idea that we're purposefully creating conflicts isn't right/will be repeated. 16:22:59 ack ivan 16:24:37 ivan: In any case, we do have a general problem, which isn't necessarily AS-related, but that requires a longer/more difficult discussion in the future. The fact that the context file for VC uses `@protected` feature, it has very good reasons, I don't deny that, but that's the source of the problem. That's why they can't directly put an AS into a VC without any change. 16:24:56 ivan: Whether the usage of `@protected` or not or whether other features could be used instead, I'm not really an expert in using these. 16:25:04 ivan: That might be a discussion for a future version, I don't want to get into this right now. 16:25:27 Topic: VCDM Issue Processing 16:25:30 gkellogg has joined #vcwg 16:25:35 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc 16:25:45 dlongley: bottom line from me is that they want to use the same JSON keys with different meanings and that creates issues. 16:25:51 q+ 16:25:53 subtopic: https://github.com/w3c/vc-data-model/issues/1192 16:26:10 ack manu 16:26:32 manu: I will do this -- anything that's assigned to me, I have 9 issues assigned to me, as a ready for PR issue, I will do all of those. 16:26:42 manu: Feel free to check in on each one, but my answer will be "I will raise a PR for this". 16:27:00 brent: So the main question will be -- do you need any group discussion or decision from the group? 16:27:05 q+ 16:27:05 manu: Nothing needed here. 16:27:15 subtopic: https://github.com/w3c/vc-data-model/issues/1176 16:27:21 ack JoeAndrieu 16:27:28 s/from me is that they/from me is that we (and they)/ 16:27:40 JoeAndrieu: If anyone has feedback I'm happy to hear it but I'll get to this I have what I think I need. 16:28:06 subtopic: https://github.com/w3c/vc-data-model/issues/1239 16:28:15 q+ 16:28:20 ack ivan 16:28:21 brent: Expires header for HTTP is in the past... 16:28:33 ivan: I looked at that. And I made a relatively longer comment on Jan 35. 16:28:36 s/35/25/ 16:28:49 ivan comment https://github.com/w3c/vc-data-model/issues/1239#issuecomment-1909419258 16:29:25 ivan: Essentially what happens is that, if we solve it now to change the .htaccess the way it should be, it would put the same expires settings to our context files as well. Simply because, the way I found it, you can't put these access things on an individual file, just different types. 16:29:29 ivan: I can't put it on a single file. 16:29:57 ivan: This change can be done, but my proposal is to not do it now during development but we should flag to do it when we go to PR or REC when freezing the content isn't a problem anymore. 16:30:02 brent: So we can label this as before PR. 16:30:09 ivan: Or before REC even. 16:30:32 ivan: There will be a point, actually, and we'll have to come back to this, where some of the files, which are currently on github should be moved to W3C space to be secure by all the backup features, etc. 16:30:45 ivan: That has to be done at some point in the future, that's also related, so for the time being we should not touch all this in my view. 16:30:55 brent: Proposal is not to do anything, sounds like Ivan has a good view for the path forward. 16:31:02 brent: Any comments? 16:31:18 subtopic: https://github.com/w3c/vc-data-model/issues/1388 16:31:19 q+ 16:31:27 brent: Specify what kind of processing is safe on a returned document. 16:31:31 ack manu 16:31:34 brent: Do you need feedback? 16:31:35 manu: I do. 16:31:45 manu: On Jan 3rd, Jeffrey gave us some options to make him happy. 16:31:46 Jeffrey noted these things as options to mitigate his concerns: https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1876019676 16:32:13 manu: I think if we do the first thing -- that he listed. His three options as alternatives, the first option is to basically say: "If a verifier doesn't understand a claim, they can ignore it". 16:32:43 manu: The second one is, "Create a new section in the spec that provides instructions for people creating vocabularies and credential types where they say what processing is safe/not safe." 16:32:51 manu: I think that's a significant amount of work to figure out what to say there. 16:33:14 manu: The third one is, really a question about an authorization and a claim ... we speak to that in the implementation guide already, I think. 16:33:32 q+ to suggest shifting away from "safe" 16:33:45 manu: I think we should do the first thing and say that a verifier can ignore ... I don't think we can make a normative statement because it's business rules, but "it's expected that a verifier will ignore claims that it does not understand". 16:34:00 manu: It's also expected that a credential type would say what's mandatory and what's optional. 16:34:12 ack JoeAndrieu 16:34:12 JoeAndrieu, you wanted to suggest shifting away from "safe" 16:34:14 manu: I'm looking for anyone objecting to those kinds of statements at this point. 16:34:29 JoeAndrieu: My first question ... of those two statements -- are they in IRC or in the issue? 16:34:33 manu: They are just in my head unfortunately. 16:34:38 q+ to avoid the word "safe" 16:34:51 JoeAndrieu: I had a hard time following -- I don't understand the framing of "safety" and it concerns me. Because processing JSON isn't unsafe. 16:34:56 ack manu 16:34:56 manu, you wanted to avoid the word "safe" 16:34:56 JoeAndrieu: I think it's a weird semantic. 16:35:29 manu: +1 to avoid that word. Jeffrey's concern was that it may be possible to construct something in JSON-LD that is then read by a credential-type-specific process that makes it misconstrue some of the statements. 16:36:02 manu: It presumes there is zero JSON schema checking and so on -- that all the production scale deployments I know of are checking their inputs for a certain structure. 16:36:12 q+ 16:36:35 manu: He's saying that if you don't tell people about that, then it's not safe. But that falls into the category of "If you don't check your program inputs, that's bad", just like SQL injection attacks, etc. 16:36:45 manu: +1 to not talk about safe/unsafe but talk about expectations when inputs are provided. 16:36:50 ack JoeAndrieu 16:36:56 JoeAndrieu: That all sounds great I'll look for your language. 16:37:26 JoeAndrieu: My frustration is that I don't think I've ever seen this type of thing from any other Web standard. I don't recall being told what I can do with an HTTP response. Any data I get could be an attack, I think this is just weird framing. 16:37:56 subtopic: https://github.com/w3c/vc-data-model/issues/1291 16:38:17 brent: Do you need feedback on this one, Manu? 16:38:22 q+ 16:38:31 manu: I think this example should be in the status list spec, so let's transfer that over there. 16:38:44 manu: So I think we already have a multi-purpose list over there so we might be able to close this. 16:38:50 pauld_gs1 has joined #vcwg 16:38:53 manu: The only problem is that it's not clear what implementers prefer to do over there. 16:38:53 q+ 16:38:58 present+ 16:38:59 ack ivan 16:39:01 manu: Short answer is to transfer for status list. 16:39:27 ivan: This is fully procedural, this issue is labeled post-CR but is put on the expires thing. What's that mean? 16:39:35 brent: post-CR says we can talk about this when we're in CR. 16:39:42 ivan: Then another issue needs to be changed to post-PR or something like that. 16:40:39 brent: So the suggestion for 1291 is to move the issue to bitstring status list and address it there. 16:40:47 brent: The question that comes to my mind is -- is that sufficient? 16:41:07 q+ 16:41:09 brent: Theoretically, bitstring status list will be one of many that might go into the `credentialStatus` property all at the same time. 16:41:25 brent: Is there sufficient language around the core data model for this -- or does the core DM need some language? 16:41:26 ack manu 16:41:47 manu: That's an excellent point, I take back my proposal. Maybe what we should do here instead is provide an example of multiple status lists and just use BSL as the two entries. 16:42:11 manu: Proposal is to add an example under `credentialStatus` with one that has revocation and another that has suspension. 16:42:34 brent: And a line that says check the status list specs to see how to handle things. It's possible for multiple statuses to exist and be contradictory and what you do with them is up to you. 16:42:36 manu: Sounds good. 16:42:43 gkellogg has joined #vcwg 16:42:51 subtopic: https://github.com/w3c/vc-data-model/issues/1274 16:43:05 brent: Tell a little bit more about verification method type schema. Do you need feedback, Manu? 16:43:40 manu: The path forward here is to delete the note and I'll do that. 16:43:43 brent: Yes, agree. 16:44:00 subtopic: https://github.com/w3c/vc-data-model/issues/1410 16:44:22 brent: Do you need feedback on this one, Manu? 16:44:56 manu: The proposal here is "no", we should not add a normative credential types spec, it would be extra work, it's not clear what we would put in it; unless people feel strongly about this, my proposal is to mark pending close and say we won't be adding it. 16:45:09 manu: Saying we won't add that section this time around. 16:45:23 brent: Anyone disagree and think we should get normative in the credential types specification? 16:45:29 brent: No objections. 16:45:57 brent: Especially since we'll have another PR that adds some clarity here. 16:46:00 subtopic: https://github.com/w3c/vc-data-model/issues/1299 16:46:13 brent: Address normative statements in non-normative sections. 16:46:24 q+ 16:46:29 q- 16:46:38 brent: We talked about this three weeks ago. I should have marked it pending close last time, sorry folks. 16:46:52 brent: A PR addressed this, that happened, this has been addressed. 16:46:55 +1 to close because it's been addressed. 16:47:05 brent: I will close this after the meeting today. 16:47:20 present+ 16:47:38 subtopic: https://github.com/w3c/vc-data-model/issues/1303 16:47:39 brent: Remove the at-risk marker for evidence. 16:47:50 brent: This is on our list of before-PR actions to take, Manu do you need anything? 16:48:16 manu: I added another issue to track this. Can we close this one? 16:48:26 manu: We're tracking it elsewhere. 16:48:35 brent: I believe the other one covers this. 16:48:46 brent: Proposal is to close this one because an umbrella issue is tracking this one. 16:48:48 q+ 16:48:51 +1 to close because it's being tracked in 1437 16:48:51 brent: Anyone opposed? 16:48:56 ack DavidC 16:49:14 q+ 16:49:21 ack manu 16:49:22 DavidC: I'm not opposed to closing at all. We ought to make a note somewhere that if any of these have had the at-risk marker removed then they fail the conformance testing, then they need a W3C-CCG spec written for them? 16:49:31 q+ 16:49:39 manu: No, they need a spec somewhere for them. Where we see two different implementations being able to handle the markup for it. 16:49:47 manu: I think the resolution a couple of weeks ago -- and we did minute it... 16:50:04 manu: Was that spec has to exist, multiple implementations must exist, but the only thing this WG needs is an example that uses the markup from that other spec. 16:50:33 manu: And request that the issuers issue a VC with that stuff -- and if they can do that, (multiple issuers), e.g., multiple issuers with evidence do it, then we're good, the feature stays in the spec. 16:50:47 DavidC: If they don't pass that threshold, my understanding is that a CCG spec should exist. 16:50:49 manu: It's any spec. 16:51:00 ack ivan 16:51:02 DavidC: We may need to change the wording, the description, I'll go look again. 16:51:13 ivan: I may ask the same question as David just differently. 16:51:42 ivan: These properties in the vocabulary, they refer to a CCG document for their normative description; as long as they are an extension point and not really part of the vocab and that's ok. If we remove that marker and they become bonafide properties... 16:51:45 q+ 16:51:50 ivan: Then we have to have normative text in the VC spec to refer to. 16:51:54 ivan: Just making sure this will happen. 16:51:57 ack manu 16:52:38 manu: My understanding is that the extension specification, the only thing that is required for the extension point, is that we have a test in the VCDM 2.0 test suite. So looking at "evidence", we have a test in the VCDM 2.0 test suite, it has an evidence field that is populated using an external spec. 16:52:45 manu: It has another context for that evidence extension. 16:52:56 manu: And there will be a type that's used in the evidence field that uses that extension property. 16:53:07 manu: We don't have to do anything else. I think that's the agreement that the group came to. 16:53:13 q+ 16:53:27 ack ivan 16:53:28 manu: We have to demonstrate a spec is out there, multiple people using it, we test that with a test here in the VC 2.0 test suite. 16:53:50 q+ 16:54:02 ivan: I am looking at the vocab spec. The evidence refers back to the data model, so we're fine there. The same with `refreshService`, but `renderMethod` refers to a CCG document. 16:54:05 ivan: That's what I'm worried about. 16:54:23 ack manu 16:54:25 ivan: All the others refer back to the VCDM spec as the source for the property specification, I'm worried just about `renderMethod`. 16:54:40 manu: I don't think `renderMethod` and `confidenceMethod` will make it into the main spec, but they will be reserved. 16:54:44 ivan: Ok, just wanted to make sure. 16:55:10 subtopic: https://github.com/w3c/vc-data-model/issues/1348 16:55:11 brent: Manu, do you need anything on this one? 16:55:32 manu: This one scares me ... it's not one issue, it's like 30 things that Jeffrey would like to have changed but they are all in theory editorial. This one will take the longer amount of time. 16:55:49 manu: I'm afraid a single normative thing will come up. We have time, but I need to prioritize. 16:56:21 brent: It's good that we've wrapped around on the issue discussion. Hopefully we'll positively increase the pressure to get these done. 16:56:25 brent: Thank you Dave for scribing. 16:56:27 rrsagent, draft minutes 16:56:28 I have made the request to generate https://www.w3.org/2024/02/28-vcwg-minutes.html ivan 16:56:35 dlongley: welcome! 16:56:53 rrsagent, bye 16:56:53 I see no action items