14:16:12 RRSAgent has joined #vcwg 14:16:16 logging to https://www.w3.org/2024/04/10-vcwg-irc 14:16:16 RRSAgent, make logs Public 14:16:17 please title this meeting ("meeting: ..."), ivan 14:16:26 Meeting: Verifiable Credentials Working Group Telco 14:16:26 Date: 2024-04-10 14:16:26 Agenda: https://www.w3.org/events/meetings/0d074559-1457-4540-857b-24b1be7a8d7f/20240410T110000/ 14:16:26 chair: brent 14:16:27 ivan has changed the topic to: Meeting Agenda 2024-04-10: https://www.w3.org/events/meetings/0d074559-1457-4540-857b-24b1be7a8d7f/20240410T110000/ 14:24:37 TallTed has joined #vcwg 14:57:49 present+ 14:57:57 present+ pauld 14:59:23 brent has joined #vcwg 14:59:25 steele has joined #vcwg 14:59:54 present+ 15:00:38 TallTed has joined #vcwg 15:00:48 present+ manu 15:01:13 present+ TallTed 15:01:37 present+ davidc 15:01:47 present+ dlongley 15:01:52 DavidC has joined #vcwg 15:02:00 present+ 15:02:14 present+ 15:02:23 present+ bigbluehat 15:02:35 dmitriz has joined #vcwg 15:02:48 present+ dmitriz 15:03:10 bigbluehat has joined #vcwg 15:03:19 present+ 15:03:38 pauld_gs1 has joined #vcwg 15:03:46 present+ 15:03:49 scribe+ 15:04:32 brent: agenda today - work items, issue processing. 15:04:35 q+ 15:04:47 ack ivan 15:04:48 ... any changes to the agenda or preferences? 15:04:59 ivan: last week we said we'd vote for CR transition - was it today? 15:05:08 ... at the moment, the day we had in mind was the 18th, which is next Thurs 15:05:27 ... to do that, necessary to vote for it today. tho there are still minor issues to be settled before I can send it to management, and I dont' see Gabe 15:05:34 brent: both Gabe and Mike are unable to join 15:05:39 ivan: we'll have to postpone the CR 15:05:43 brent: confirmed. 15:05:48 q+ to note next week is IIW 15:05:51 ... we'll deal with it next week 15:05:58 ack manu 15:05:58 manu, you wanted to note next week is IIW 15:06:08 manu: next week is IIW, and I expect a decent chunk to be gone for that as well 15:06:16 q+ 15:06:20 ... I'm wondering if we could vote today anyway, and put it out to the mailing list to see if anyone objects 15:06:43 ... I realize it's weird to do a vote without editors here, but I think everyone on the call last week heard that we'd do it this week, and people still have 7 days to object 15:06:56 ... I'm afraid if we don't do it this week, next week we won't have enough people again, and it'll keep being delayed. 15:06:57 ack ivan 15:07:19 ivan: that's one aspect, the other is - Gabe put out a CR text in a separate branch / PR. and I had some comments on the text that need to be addressed before merging 15:07:36 ... so, the vote is one thing, final CR is another thing. and I don't feel like going there and doing changes myself (not even sure I could) 15:07:59 ... if we vote today, it will not make things faster 15:08:11 smccown has joined #vcwg 15:08:16 brent: I don't mind putting a proposal in front of the group today as long as we can craft it properly 15:08:38 ... Gabe mentioned to me that he was going to try and mend the PR with the draft; I don't see any current changes on it though 15:08:51 ... if someone would like to craft a proposal to put in front of the group, I'm happy to run it 15:09:00 ... I'm still planning to be on the meeting next week, even though it's IIW 15:09:15 ... and if there's not enough people, it'll be a brief meeting 15:09:20 ... anyone opposed to a proposal today? 15:10:01 q+ 15:10:07 ack DavidC 15:10:31 DavidC: I was just looking at the list of issues; there are a lot of issues, all flagged Post-CR. do we know for certain that when those issues are resolved, they won't require a second CR? or is not a problem? 15:10:35 ivan: not a problem 15:10:51 brent: I trust editors to triage appropriately 15:11:03 ivan: to be clear, PR 265 must be addressed before we go on, but that's understood 15:11:09 PROPOSAL: Publish the vc-jose-cose specification based on https://pr-preview.s3.amazonaws.com/w3c/vc-jose-cose/pull/265.html as a W3C Candidate Recommendation with a 28 day CR period and a target date of April 18th for publication. 15:11:13 +1 15:11:13 +1 15:11:15 +1 15:11:16 +1 15:11:19 +1 15:11:23 +1 15:11:25 +1+1 15:11:35 me :) 15:11:38 +1 15:11:44 s/+1+1/+1 15:11:52 present+ smccown 15:11:55 s/me :)// 15:12:02 +1 15:12:06 RESOLVED: Publish the vc-jose-cose specification based on https://pr-preview.s3.amazonaws.com/w3c/vc-jose-cose/pull/265.html as a W3C Candidate Recommendation with a 28 day CR period and a target date of April 18th for publication. 15:12:09 RRSAgent, draft minutes 15:12:10 I have made the request to generate https://www.w3.org/2024/04/10-vcwg-minutes.html TallTed 15:12:18 brent: thanks all! 15:12:34 Topic: Work Item Status Updates/PRs 15:12:36 ... let's jump into next topic 15:12:38 q+ 15:13:01 brent: I'm happy to announce that the status of vc-jose-cose has been approved to go to CR, hopefully a smooth transition 15:13:23 ... number of post-cr issues on it, I trust will be resolved in due time. I do know the test suite for vc-jose-cose is in need of work; we have commitment from some people to do that though 15:13:25 s/Date: 2024-04-10// 15:13:25 ack manu 15:13:30 manu: thanks brent, just to go over the other specs, 15:13:54 ... we'll get to issue processing later. We have a healthy (small) list of issues on the core data model. that one media type discussion we need to have, the only real big question remaining 15:14:04 ... a number of PRs on vc dm that need to be processed; largely editorial 15:14:12 s/manu, you wanted to note next week is IIW// 15:14:20 RRSAgent, draft minutes 15:14:22 I have made the request to generate https://www.w3.org/2024/04/10-vcwg-minutes.html TallTed 15:14:29 q+ 15:14:29 ... for Bitstring Status List, I believe we have all the issues under control, would allow us to suggest a Candidate Rec post april 21st 15:14:57 ... noting that we have actually had significant reviews from PING and the security group is aware of it, and is planning to do a review before or during CR 15:15:34 ... the rest of the technical issues feel like theyr'e under control (internationalization - we do have an answer, if slightly shaky, around the messages in status list -- they're meant for devs not end users, so it's ok not to have i18n tags on them 15:15:42 ... if we change our mind in the future, we can just use standard JSON-LD tags 15:16:08 ... the potential F.O. about status list VCs being able to be changed after issuing, there's a PR for that (164) 15:16:24 Ensure that status messages are committed to at issuance time: https://github.com/w3c/vc-bitstring-status-list/pull/164 15:16:30 ... which should address PING's and Joe's concerns around that 15:16:57 ... although there have been questions raised around -- if messages have meaning only to developers, does that mean anything. I don't think those will lead to any kind of objections 15:17:15 manu: bitstring status list is on a good path towards the end of April, so heads up to chair & editors 15:17:23 ack ivan 15:17:24 ... should I prep the doc for CR, and of so, what's the target date? 15:17:41 q+ 15:17:47 ivan: there is an issue, 157, that requires manipulation on the repo level, you should take a look at 15:17:59 ack manu 15:18:03 manu: +1 that needs to be fixed, I'll take a look 15:18:08 ... that's a 'during CR' though 15:18:13 ivan: should be done before 15:18:17 manu: ok, let me change the label 15:18:57 ... i'll handle it during my next edit cycle 15:19:09 ... moving on to DI issues. VC DI is drawing a number of editorial changes, 3 are normative 15:19:29 ... which will trigger a 2nd CR. same is true for ecdsa- and eddsa-, and probably BBS- as well, so look for PRs on those specs in the next few weeks, 15:19:34 ... based on implementer feedback 15:19:43 ... sometimes in normative statements, which is good, that's what CRs are for 15:20:07 ... nothing major has come up though during CR though, no catastrophic security vulns, no formal objections brewing, etc 15:20:14 ... I think that's true of all of our CR docs at this point 15:20:25 brent: thank you manu. in general, regarding Bitstring Status List 15:21:12 ... as soon as the docs are ready to move forward, we can move them forward 15:21:20 acknowledged, we'll do that ^ 15:21:24 present+ joe 15:21:25 ... let's go to our VC DM issues 15:21:30 Topic: VCDM Issues 15:21:31 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc 15:21:57 brent: first one we don't need to talk about, 1437, we know that needs to happen 15:22:06 ... next one is 1239, we know that needs to happen 15:22:13 JoeAndrieu has joined #vcwg 15:22:15 subtopic: https://github.com/w3c/vc-data-model/issues/1462 15:22:22 ... next topic to discuss is - 1462, revisit VC media type 15:22:29 https://mailarchive.ietf.org/arch/msg/media-types/iWc8TLcWOyO0jyqeiuF9VCZClIs/ 15:22:40 ... here's a link to the discussion that's continuing among the media type mgmt WG at IETF 15:22:55 ... it's a long discussion, a number of us have taken part in it, have shared opinions 15:22:59 q+ 15:23:06 ... manu, if you would be willing to give the group a summary of where the thread has gone? 15:23:11 ack manu 15:23:29 Summary of what has happened to date: https://github.com/w3c/vc-data-model/issues/1462#issuecomment-2016609877 15:23:29 manu: I won't go into the summary in too much depth, there's a link to it here 15:23:45 ... we need to register a media type for VCs, we suggested using one that uses multiple suffixes, that has led to a long discussion at IETF over the past 5+ years 15:23:57 ... we thought we were done as of last IETF, that was not the case, we don't know when we're gonna be done 15:24:12 ... we're probably at the point that this group can't wait any longer for "the right thing to happen" 15:24:38 ... a number of options has been brought up -- from use suffixes, to deprecate suffixes, and every variation in between 15:24:52 ... based on the last 2 weeks, seems like eventually IETF is going to allow people to do whatever, in certain patterns and categories 15:25:04 ... people are definitely using suffixes in some kind of ways, there seem to be different philosophies on it 15:25:33 ... the outcome if we don't try and force the discussion to terminate any time soon is -- everything registered in the past in fine, here's some guidance for the future (for media types w suffixes) 15:25:50 ... so what it seems like will happen, they'll punt the explanation of what suffixes mean back to the spec that is registering the suffix 15:26:06 ... like "this is the media type we're registering, this is what suffixes mean, etc" 15:26:22 ... we thought this was gonna end 6 months ago, and it hasn't yet, so that's where we are today 15:26:35 ... we can take a couple of paths forward. there was the 'exception path' where we can register whatever 15:26:56 ... option b was - not use any suffixes at all, and just use application/vc and /vp 15:27:11 ... and then for SD-JWT, you can add +jwt to the end of that 15:27:18 ... option c was - wait until discussion ends at IETF 15:27:33 ... as the editor of that spec, I don't know when that will actually happen. might be within 6 months. 3 months unlikely 15:27:52 ... I wouldn't be surprised if it went on for another year. Option C is - we're not gonna register a media type until the WG figures it out 15:28:17 ... there has been some discussion in the issue; my gut tells me that Option B would result in us being able to register it immediately with no major pushback 15:28:30 ... at the same time, it's not necessarily ideal, as some people are pointing out 15:28:40 ... there are likely more technically correct ways to address the issue 15:28:55 ... another option not there in the beginning, coming from Mozilla / Martin Thompson, was - our spec can say, here's the base media type, 15:29:13 ... however you can ALSO use these other media types -- you can serve it as application/ld+json, or something else, and here are the rules for doing it that way 15:29:15 q+ 15:29:19 q+ 15:29:19 ... that would require a decent bit of discussion 15:30:06 brent: I'm wondering -- my perspective, chair hat off, it seems like one of the reasons we'd want to move forward with a media type registered now, is because a data format that has a media type registered, there's a perception that it's "a real thing", 15:30:20 ... like, we've graduated, we're real, we have a media type, I think that's the perception 15:30:28 ... so from that perspective, it'd make sense to move forward and claim one 15:30:29 q+ to mention the "it's a real thing" perception ... is a real thing. :) 15:30:58 ... the pros of option A, and moving forward w that, is that multiple suffixes make sense to us. drawbacks -- registration of multiple suffixes media types will be used for all time as a bad example 15:31:10 ... and I don't want to be painted with that brush 15:31:22 ... I recognize the drawbacks of choosing something simple like application/vc 15:31:35 ... or you can just use ld+json in our description of the media type 15:31:37 ack brent 15:31:42 ack ivan 15:31:54 +1 to registering `application/vc`, `application/vp`, and saying that `application/ld+json` is also permitted -- and keeping open the option to add multiple suffixes in the future 15:31:54 ivan: I am pretty worried about all of these things; we've been fighting w this for I don't know how many years now 15:32:17 ... if we're getting to a registration of something that won't be really accepted by IETF, it leads to a lot of discussion, and at the end of the day, it will create problems for the final TR 15:32:39 ... in the meantime, it's a lot of discussion; I don't remember how many media types we're talking about, and to add jose/cose to it, we're talking about 6 or 7 media types we have to fight for 15:33:07 ... and I don't feel like doing that. I repeat what I said last week, I still believe an option is, we either don't do anything right now, or just try and register /vc and /vp 15:33:13 q+ 15:33:24 q- later 15:33:30 ... additionally, we have this pending charter proposal that we have to talk about at some point 15:34:00 ... and we should add to the charter proposal -- if IETF takes a final stand, and if it allows us to register ld+json or whatever, we can do it in the next incarnation of the WG, and we don't do it now. I think that's the best option 15:34:03 ack TallTed 15:34:36 TallTed: my sense of the IETF position at this moment is - there are a couple of very loud voices who have been around for a while, and type a lot, who are very much against what is being called "multiple suffixes", which I think of as sub-subtypes 15:34:55 ... it is not my sense that this is an IETF position as a whole, or even just of the decision makers 15:35:14 ... I don't think we should be scared off from doing the right thing, because we think it won't get through 15:35:31 ... most of us have a sense of how media types have worked historically, and that is not what is currently being trumpeted by the loud voices 15:35:50 ... the loud voices are saying, everything we've been doing historically is wrong, and we won't do it anymore. that should be objected to, by as many voices as poissible 15:36:10 ... there are some errors in what has been registered in the past, and there are some errors in what's being requested in the jose/cose thread 15:36:51 ... there's other options, and I believe those won't get objections from IETF 15:36:51 ... the timing sucks, no way around that 15:36:59 ... but I don't want to do anything that precludes us doing the right thing as time moves on 15:37:06 q+ to note "doing the right thing" as time moves on. 15:37:07 ... IETF is giant in scope 15:37:20 ... but it's also a giant cruise ship, difficult to turn quickly. more voices help in that 15:37:59 ... partly because more voices can put it in different words, and can be heard differently. if you haven't participated in the thread, and understand what we're trying to do, weigh in 15:38:08 ack manu 15:38:08 manu, you wanted to mention the "it's a real thing" perception ... is a real thing. :) and to note "doing the right thing" as time moves on. 15:38:23 manu: I agree with a lot of what Ted said, I do think there is a minority opinion driving the discussion at IETF 15:38:51 ... I am still hopeful we can come to something that won't undo 20-30 years of media registrations. But that's not our fight. in this group, we just need a media type 15:38:54 ... I'm a strong +1 to what Brent said, that when you have a media type, something is real 15:39:07 ... for better or for worse. so let's pick a media type that does not limit our future options 15:39:33 ... for example, one thing we can do (I'm willing to write a PR), is to say, we're registering application/vc and /vp, today 15:39:42 ... and for the jose/cose specs, we can add a +jwt to it 15:39:57 ... in theory, that matches everythign done previously, won't get pushback 15:40:13 ... and in our specs, we can say, alternatively, you may serve things as application/ld+json, 15:40:21 ... we'll make a very strong case for application/vc 15:40:30 ... but if you want general semantics, you can just do ld+json 15:40:53 ... in the future, if the multiple suffix stuff gets to consensus, in a future spec, we can say, you may serve it as application/vc+ld+json 15:41:02 q+ 15:41:15 ... the only downside to that approach is - all of a sudden, we have potentially 3 media types. but it's not that difficult for software to deal with 3 15:41:26 ... we do have one issue regarding file extensions. 15:41:39 ... which you can associate with just one media type, if I remember correctly. but that's a smaller problem to deal with 15:41:48 ack ivan 15:42:13 ivan: i have the impression that we are widely agreeing. the only thing I'd ask for this PR, which I agree with, can you also make a PR which adds something into the charter proposal for the future WG 15:42:24 ... or, rather, the maintenance WG 15:42:30 manu: happy to do that 15:42:39 brent: sounds like we have a path forward 15:42:55 ... we'll see how the discussion pans out with the PR. seems like we're in a place where that PR can be written 15:43:13 subtopic: https://github.com/w3c/vc-data-model/issues/1348 15:43:20 q+ 15:43:26 brent: 1348, non-normative changes from J Yaskin 15:43:26 ack manu 15:43:53 manu: i would love help on this, not sure how to distribute the task, other than people picking sections from the big long list 15:44:06 ... if people want to take sections from the bottom of that list, that'd be awesome 15:44:21 ... there's roughly 35 changes that need to be made. not too bad, most of those should be editorial. 15:44:28 q+ 15:44:29 ... so, volunteers welcome 15:44:38 ack DavidC 15:44:53 DavidC: the bit I've done is nearly agreed on now. the one thing I don't know how to do is to add a reference to an external document 15:44:54 q+ 15:45:03 ack manu 15:45:19 manu: at the top of the document, there's a section called Biblio or something like, that has a bunch of square brackets, that's where you add it 15:45:42 ... if you're referencing an existing RFC, those should be there already, you just need double brackets around RFC 15:46:03 https://github.com/w3c/vc-data-model/blob/main/common.js#L7 15:46:09 DavidC ^ 15:46:11 DavidC: I couldn't find that section 15:46:51 manu: ok, yeah, what dlongley said 15:46:56 note that this: https://github.com/w3c/vc-data-model/blob/main/index.html#L48 links to that common.js file. 15:47:02 https://github.com/w3c/vc-data-model/pull/1469 15:47:10 brent: just to note for the minutes, PR 1469 is DavidC's PR that he's addressing 15:47:17 https://github.com/w3c/vc-data-model/pull/1464 15:47:19 ... and manu's PR for the rest is 1464 15:47:29 ... and as has been mentioned, please feel free to claim a section and work on it 15:47:46 ... moving on to 1472 15:47:49 subtopic: https://github.com/w3c/vc-data-model/issues/1472 15:48:08 brent: Ted, it's your issue, do you want to walk us through 15:48:21 TallTed: possibly just deleting that paragraph 15:48:21 q+ 15:48:32 ... the problem with "trust" at all is, it's outside the bounds of what we can really do 15:48:51 ... we're cryptographically assuring that contents are the statements of the issuer, that's it 15:48:54 ... there's nothing about the truth of them, or anything else 15:49:05 ... just "this issuer said these things at this time" 15:49:10 +1 to TallTed 15:49:15 ... so talking about truth in the context of revocation doesnt make sense 15:49:15 +1 to TallTed 15:49:20 ack manu 15:49:26 manu: +1 to that, Ted. 15:49:32 +1 to just remove the paragraph 15:49:35 ... I think we do have, in some other part of the spec, exactly what you said 15:49:45 +1 to remove paragraph 15:50:05 manu: I think it is generally presumed that you're going to listen to the issuer, but of course there are cases where you might not trust em 15:50:12 q+ to say there is trust that the issuer is in control of the mechanisms 15:50:25 ... or just a subset of what they're saying. I reacted strongly to "lets just delete it", but now that I'm reading it, if we have that language elsewhere, 15:50:47 ack JoeAndrieu 15:50:47 JoeAndrieu, you wanted to say there is trust that the issuer is in control of the mechanisms 15:50:51 ... do you want to take this issue? 15:50:51 TallTed: yeah, I'll take it, 15:51:12 JoeAndrieu: this is a really good catch, Ted. I agree we don't have to depend on the trust. might be useful to say something about trusting that the issuer is using the mechanism correctly 15:51:29 brent: sounds like we have a path forward, look forward to the PR 15:51:33 subtopic: https://github.com/w3c/vc-data-model/issues/1457 15:51:39 q+ 15:51:48 brent: we discussed this one a few weeks ago 15:51:53 ack manu 15:52:09 manu: David Lehn is working on it, just has a long backlog, he'll get to it 15:52:31 ... suggestion was - we update ReSpec VC, not only show data integrity securing mechanisms, but some of the VC-JOSE/COSE mechanisms 15:52:50 subtopic: https://github.com/w3c/vc-data-model/issues/1465 15:52:51 ... in the respec vc library, would allow you to choose on an example-by-example basis which securing mechanisms you'd want to show 15:52:51 brent: thanks 15:53:10 brent: I raised this. I was reading through spec, and noted that two different sections both talk about the credential lifecycle 15:53:14 ... so the split is not great 15:53:24 ... let's merge them into one section. take 3.4, put it inside of 5.1 15:53:40 ... also remove the concrete example, say - "we have use cases, they're over there", like we've done in the path 15:53:42 q+ 15:53:46 ... would love to hear feedback. 15:53:53 ack manu 15:54:09 manu: strong +1 to that. I'm wondering if we should go a step further, and merge that section into the Use Cases document 15:55:09 brent: proposal on the table is, in as minimal fashion as possible, merge those two sections, and reference the Use Cases doc, like Joe said 15:55:10 +1 15:55:19 JoeAndrieu: sounds right 15:55:26 brent: ok, I'll do that 15:55:34 ... Joe, does the Use Cases doc have this lifecycle stuff? 15:56:06 JoeAndrieu: I think it's there, but we'll check 15:56:11 brent: ok, we're at time, thanks everyone 15:56:34 ... before we close, I do want to note issue 1467, I made a chair statement on that, I'm not seeing any new info that justifies the conversation taking further time 15:56:51 ... that said, if in the comments of the issue and the resulting PR, if people can come to consensus on the way forward, I won't step in the way 15:56:56 ... I'm just not seeing consensus form. 15:57:23 rrsagent, draft minutes 15:57:25 I have made the request to generate https://www.w3.org/2024/04/10-vcwg-minutes.html ivan 15:58:25 rrsagent, bye 15:58:25 I see no action items