15:37:01 RRSAgent has joined #vcwg 15:37:06 logging to https://www.w3.org/2023/12/13-vcwg-irc 15:37:07 RRSAgent, make logs Public 15:37:08 please title this meeting ("meeting: ..."), ivan 15:37:19 Meeting: Verifiable Credentials Working Group Telco 15:37:19 Date: 2023-12-13 15:37:19 Agenda: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231213T110000/ 15:37:19 chair: brent 15:37:20 ivan has changed the topic to: Meeting Agenda 2023-12-13: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231213T110000/ 15:48:18 brent has joined #vcwg 15:48:29 present+ 15:54:19 present+ 15:57:10 andres has joined #vcwg 16:00:36 present+ 16:02:01 present+ bigbluehat , dlongley, manu 16:03:05 present+ 16:03:09 dmitriz has joined #vcwg 16:03:15 present+ 16:03:17 DavidC has joined #vcwg 16:03:17 present+ davidc, dmitriz 16:03:24 present+ 16:03:42 Will has joined #vcwg 16:03:43 present+ 16:03:54 present+ will, nsteele, orie 16:04:34 Orie has joined #vcwg 16:04:35 present+ 16:04:35 scribe+ 16:05:27 Agenda: status updates, prs, issue triage, discussion 16:05:45 brent: any agenda bash? 16:05:48 q+ 16:05:51 Topic: Work Item status updates/PRs 16:05:57 ack manu 16:06:27 manu: please review the special topic call minutes... seems the outcome is to publish CR drafts for data integrity specs, and integrating feedback that will trigger second CR 16:06:54 ... we are going to try to close issues aggressively 16:07:04 ... we will try to close PRs that are not going to make it 16:07:16 present+ seabass 16:07:27 ... with that said, data integrity specs have some changes, that will be merged this weekend 16:07:49 ... we should publish vc specs directory, because its blocking the data model from entering CR 16:08:07 ... vc data model PRs are progressing 16:08:28 ... greg is adding a bunch of content on privacy and security considerations for bbs 16:08:49 ... we will request horizontal review for that spec in prep for CR for BBS 16:08:58 s/has/greg has/ 16:09:02 ... we just started test suites for data integrity bbs 16:09:15 present+ joeandrieu 16:09:23 brent: any PRs you want to include in the minutes? 16:09:33 scribe+ 16:09:41 JoeAndrieu has joined #vcwg 16:10:31 Orie: There are two PRs open, one of them is regarding our media types and I don't think that'll go in. 186, removes registrations for multiple suffixes... WG seems to believe multiple suffixes is safe enough to not block publication... I expect 186 to close soon. 16:10:45 https://github.com/w3c/vc-jose-cose/pull/190 16:10:59 present+ pauld_gs1 16:11:15 Orie: There is pull 190, placeholder PR to marry to other verification PRs. This is an attempt to align w/ verification algorithm defined in core data model so core data model doesn't need to talk in detail about things that are in securing specifications. 16:11:53 Topic: Issue Discussion 16:11:55 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+sort%3Aupdated-asc 16:12:07 pauld_gs1 has joined #vcwg 16:12:09 present+ 16:12:29 q+ 16:12:29 subtopic: https://github.com/w3c/vc-data-model/issues/1337 16:12:30 brent: some have PRs exist 16:12:35 ack manu 16:12:55 manu: this one needs to be closed, we merged related PRs, and filed follow up issues 16:13:23 present+ 16:13:23 ivan: don't close things on the call, I will do it 16:13:37 subtopic: https://github.com/w3c/vc-data-model/issues/1328 16:13:50 brent: make validation normative, unsure of status 16:14:35 q+ 16:14:35 brent: seems we had some PRs 16:14:35 ack Orie 16:14:43 Orie: I think we've done about as good as we can do w/ verification algorithm PR. I think this issue can be potentially closed. I'm happy w/ the way validation is described, doing more is probably difficult and not helpful. 16:14:44 +1 to closing. better to handle in verification 16:14:55 brent: suggestion is that this is addressed and can be closed 16:15:03 ... we will close after the call 16:15:23 brent: I enjoy closing issues 16:15:29 subtopic: https://github.com/w3c/vc-data-model/issues/1360 16:15:57 ... add mechanism to secure presentation metadata, related to related resource stuff 16:16:13 ... separated from enveloped credentials 16:16:46 ... seems like we tried, and now its time to decide to close the issue... if it stays open, it will be labeled future work 16:16:51 q+ to recommend Future Work route 16:17:00 ack dmitriz 16:17:00 dmitriz, you wanted to recommend Future Work route 16:17:07 dmitriz: I recommend we label future work 16:17:37 ... this seems important, but we should leave a roadmarker for future us 16:17:58 brent: unless there is objection, I will label as future work 16:18:24 brent: I will remove the before CR label, and unassign 16:18:46 subtopic: https://github.com/w3c/vc-data-model/issues/1316 16:19:04 brent: update securing verifiable credentials section 16:19:34 ... seems there is disagreement on if its necessary, last suggestion was to wait for verification algorithm PRs to land 16:19:51 ... is there anything left for this issue? 16:20:16 q+ 16:20:25 ack manu 16:20:44 manu: i propose we close the issue, there does not seem to be consensus here 16:21:08 ... we could make it more clear that there are extension points, and proof is used by data integrity, not the other way around 16:21:27 ... perhaps more non normative text, about how proof is an extension point, used by securing mechanism 16:21:46 brent: seems like labeling post CR would be ok 16:22:39 manu: I can try to address the one normative part related to proof 16:22:47 ... let me try to take a shot at it 16:23:02 brent: I am also going to label it post CR' 16:23:29 subtopic: https://github.com/w3c/vc-data-model/issues/1364 16:23:44 brent: do VCs still need media types with multiple suffixes 16:23:58 ... short answer is yes 16:24:14 q+ 16:24:22 ... comments on this? seems we are ready to close this issue 16:24:32 ack manu 16:24:47 manu: I think we still need media types with multiple suffixes 16:25:36 ... the only thing that is in question now are the media types for the securing formats such as jose-cose 16:25:36 ... I think I agree with the existing media type registration requests 16:25:36 yes, pretty strongly, application/sd-jwt 16:25:41 ... this group will need to decide what media types to request 16:25:50 ... ted, please open your PR before the next IETF meeting 16:26:01 ... if we fail to get into last call again, everything will be very sad 16:26:14 +1 to Manu's position, I think Ted is right but relying on Ted. 16:26:17 tallted: I will get it done this week 16:26:34 brent: any other IETF PRs we want to discuss? 16:26:52 brent: labeling pending close, we think we need what we currently request 16:26:55 s/I will get it done this week/doing my best to get it done this week 16:27:05 subtopic: https://github.com/w3c/vc-data-model/issues/1377 16:27:24 brent: rewrite verification algorithm in a way that does not cause layering violations 16:27:35 ... can we close this issue 16:27:38 q+ 16:27:44 ack manu 16:28:17 manu: I think the text in the spec is not optimal, and it needs to align with the new interface langauge to align with the securing mechanism, and its done 16:28:33 ... I could not figure out how to write that text, you orie, please propose some text 16:28:45 q+ 16:28:50 ack Orie 16:29:35 Orie: Yes, seems like we're in the proces sof addressing follow-up PRs on verification algorithm. I expect those follow up PRs to resolve this. I'm not sure I have special text to add. Current language isn't acceptable, heading in a good direction. 16:29:48 brent: Can you make a concrete suggestion that would make the text acceptable? 16:29:57 Orie: Yes, I think Mike Jones is planning to do that already? I'll leave it to him. 16:30:06 brent: can you make a suggestion for text? 16:30:26 manu: I prefer to explicitly assign mike jones to this 16:30:48 brent: Mike is assigned, orie, hopefully you can communicate to mike that he is assigned 16:30:59 subtopic: https://github.com/w3c/vc-data-model/issues/1352 16:31:14 brent: add mechanism to secure VPs 16:31:32 ... first PR failed, second PR was raised, can we get an update 16:31:36 https://github.com/w3c/vc-data-model/pull/1379 16:31:45 manu: seems it will land 16:32:09 ... we seem to have a solution for securing verifiable presentations without using proof 16:32:23 subtopic: https://github.com/w3c/vc-data-model/issues/1375 16:32:48 brent: labeled with PR exists, manu can you give an update? 16:32:50 https://github.com/w3c/vc-data-model/pull/1381 16:33:15 manu: lots of approvals, some unaddressed changes and questions, does not seem to have anything blocking 16:33:29 ... it would remove a large chunk of duplicated normative statements 16:33:55 ... seems this will merge over the weekend 16:34:15 subtopic: https://github.com/w3c/vc-data-model/issues/1363https://github.com/w3c/vc-data-model/issues/1363 16:34:35 brent: request profile parameter for application/vc+ld+json 16:34:40 subtopic: https://github.com/w3c/vc-data-model/issues/1363 16:34:55 https://github.com/w3c/vc-data-model/pull/1382 16:35:00 s|subtopic: https://github.com/w3c/vc-data-model/issues/1363https://github.com/w3c/vc-data-model/issues/1363|| 16:35:05 orie: see this recent cg draft using profile: https://www.w3.org/community/reports/json-ld/CG-FINAL-yaml-ld-20231206/ 16:35:13 q+ 16:35:27 brent: not sure about the course this is taking 16:35:31 ack Orie 16:36:34 q+ 16:37:06 Orie: I think that PR is on a good track, Manu's attempting to address ambiguity, forbid profile parameter. From a design perspective, bad to say extensibility for profile is internal to media type. For awareness of the group, JSON-LD CG just published for YAML-LD that also registers profile parameter. I think it's a best practice to inherit the profile parameter the way all the other media types tend to support it and then say, when it's present, it has 16:37:06 to be interpreted in some way and if you don't have a need for it, don't use it. That would be my recommendation. This will impact registration of media types, since we're first through the door on multiple suffixes, it would be wise of us to be explicit about profile parameter. 16:37:16 ack TallTed 16:37:19 ted: I am very confused by orie's comments 16:37:37 ... the PR is titled forbid use of media type parameters 16:37:47 q+ 16:38:03 ... I take issue with forbidding parameters, media type parameters should not be forbidden' 16:38:12 ... some content still needs to be changed 16:38:17 ack manu 16:38:44 manu: seems you are missing context from the special topic, there was pushback forbidding media type paramters 16:39:06 ... you seem to want to address profile, not forbid media type parameters 16:39:30 ... we had too many objections to forbidding the profile parameter 16:39:38 ... we tried to resolve to say nothing 16:39:48 IMO, it still seems clear that we don't know what we want to say and so we should say nothing at all. 16:40:00 ... i believe orie wanted us to provide guidance on the profile parameter 16:40:03 +1 to dlongley 16:40:09 q+ 16:40:12 ... in case the media type parameter is inherited from the suffix 16:40:17 ack dlongley 16:40:41 dlongley: to me, it seems like we don't as a group know what to say here, so we should say nothing 16:40:48 orie: I am fine closing all these 16:41:05 q+ 16:41:08 brent: if nobody is opposed, lets do that 16:41:20 ack manu 16:41:36 manu: we have to remember to account for media type parameters 16:41:44 ... in the verification algorithm' 16:41:57 ... not clear how to verify if parameters are present 16:42:16 ... good to close it, but we will need to update the verification algorithm 16:42:28 brent: we have a path forward 16:43:02 subtopic: https://github.com/w3c/vc-data-model/issues/1376 16:43:21 https://github.com/w3c/vc-data-model/pull/1381 16:43:23 brent: separate verification and validation, PRs exist 16:43:39 ... we have discussed, seems it is on a good trajectory 16:43:47 ... comments? 16:44:06 subtopic: https://github.com/w3c/vc-data-model/issues/1378 16:44:16 https://github.com/w3c/vc-data-model/pull/1383 16:44:22 brent: add infra to algorithms, PR exists 16:44:31 ... seems to be on a good track 16:44:59 ... seems this will merge, and things will close 16:45:35 subtopic: https://github.com/w3c/vc-data-model/issues/1365 16:45:52 brent: clarify section of verifiable credential graph 16:45:56 q+ 16:46:02 ... what needs to change to address this? 16:46:04 ack manu 16:46:23 manu: there is a clear concern, which i think I can address 16:46:40 ... for the avoidance of doubt, the following values are not allowed in a `verifiableCredential` 16:46:49 ... I list raw text strings, and URLs 16:47:04 ... it has to be an object of some kind that creates that graph structure 16:47:32 "MUST be an object and can't be something else, such as..." 16:47:50 ... and I won't make it exhaustive... its strange to point out, what you cannot put in the field 16:47:50 works for me, thanks manu! 16:48:07 brent: do you want to mix that into 1379? 16:48:20 manu: seems to make sense to put it in 1379 16:48:26 https://github.com/w3c/vc-data-model/pull/1379 16:48:34 brent: then it will address that issue as well 16:49:05 rent: not hearing anyone opposed to this path 16:49:20 s/rent:/brent:/ 16:49:40 subtopic: https://github.com/w3c/vc-data-model/issues/1374 16:49:55 brent: specify requirements for securing mechanisms 16:49:59 ... a PR exists 16:50:01 https://github.com/w3c/vc-data-model/pull/1380 16:50:21 ... there is a request for changes from oliver 16:50:30 q+ 16:50:36 ack manu 16:51:05 manu: seems we are on a good trajectory, one thing that is concerning, he is saying verifier needs to know who the issuer of a VC is 16:51:11 ... that sounds like validation 16:51:35 ... I will try to make that a part of it, but I don't want to cover trust frameworks, or trust lists 16:52:02 ... the current text can be made clearer... the securing mechanism should not need to understand our data model 16:52:19 ... I will try to address oliver's suggestions 16:52:36 subtopic: https://github.com/w3c/vc-data-model/issues/1384 16:52:40 q+ 16:52:45 q+ to make announcement after this issue 16:52:57 ack manu 16:53:13 manu: its a misread of the text 16:53:44 ... the problem details can be exposed in production interfaces, additional problem details objects can be added to improve developer experience 16:54:17 ack Orie 16:54:17 Orie, you wanted to make announcement after this issue 16:56:01 Topic: misc 16:56:01 Orie: We made really great progress on the call today. I'll be stepping down as Editor. Transmute is going to be adjusting our strategic focus in calendar year, specs are on an excellent track. Transmute plans to implement these specifications, though can't contribute in Editor/Author capacity in the new year. Looking forward to implementing final Technical Recommendations after CR. They seem to be on a good track. 16:56:08 manu: Thank you for all the work you've put in, Orie! 16:56:08 q+ 16:56:08 ack ivan 16:56:15 rrsagent, bye 16:56:15 I see no action items 16:58:12 RRSAgent has joined #vcwg 16:58:12 logging to https://www.w3.org/2023/12/13-vcwg-irc 16:58:24 rrsagent, draft minutes 16:58:25 I have made the request to generate https://www.w3.org/2023/12/13-vcwg-minutes.html ivan 17:20:19 rrsagent, bye 17:20:30 rrsagent, set log public 17:20:35 rrsagent, bye 17:20:35 I see no action items