22:52:59 RRSAgent has joined #vcwg-special 22:53:03 logging to https://www.w3.org/2023/12/19-vcwg-special-irc 22:56:02 zakim, start the meeting 22:56:02 RRSAgent, make logs Public 22:56:04 please title this meeting ("meeting: ..."), brent 22:56:14 meeting: VCWG Special Topic Call 23:00:00 hsano has joined #vcwg-special 23:02:36 decentralgabe has joined #vcwg-special 23:03:21 chair: Brent Zundel 23:03:25 present+ 23:04:17 present+ 23:04:22 present+ 23:04:25 present+ 23:04:33 scribe+ 23:05:23 brent: This is the VCWG special topic call, our topic remains the PRs that we need to try to come to consensus on before we go into CR. 23:05:40 brent: For which we are at least we are at least a couple of months overdue but we are making progress. 23:06:04 brent: I think the current set of PRs represents or very nearly represents all the issues we need to address before, so we're in as good a spot as we can be at this point. 23:06:15 q+ 23:06:22 brent: Before jumping into the PRs, anything else to have on the agenda today? 23:06:22 ack manu 23:06:51 manu: I forgot that I sent a call out for new maintainers for the VC specs dir and the DID registry, just given Orie and Mike Prorock's current status. We got a ton of volunteers, 17 people stepped forward. I'm collecting info from them currently. 23:06:57 manu: We should talk about that for 5 minutes. 23:06:59 brent: Go ahead. 23:07:05 selfissued has joined #vcwg-special 23:07:06 Topic: VC Specs Dir maintainers 23:07:08 present+ 23:07:27 manu: Some of these folks are known to the community, others are randomly out of no where. Getting 17 people is a bit much but let's assign them and see who does the work. 23:07:54 manu: I've asked for names, github handle, and some place to know about their background and qualifications. I'm guessing the group will want to have some say over who gets assigned and when. Maybe we have a call / decide in January as a group around that. 23:08:01 manu: The VC WG that makes sense, the DID WG I don't know. 23:08:05 brent: Mailing list probably. 23:08:35 manu: I have 12 / 17 have filled out the form and we will have a call with them to figure out who runs away and who stays. 23:08:58 manu: We will put them forward as volunteers and have the group decide if there are any objections to anyone, there will still be oversight over anyone. 23:09:06 manu: That's it. 23:09:08 brent: Thank you, Manu. 23:09:13 Topic: PRs 23:09:14 brent: It's great when people step forward. 23:09:19 https://github.com/w3c/vc-data-model/pulls?q=is%3Apr+is%3Aopen+label%3Abefore-CR 23:09:31 brent: This is the link for all the PRs open and labeled before CR. 23:09:43 brent: There are 12 to discuss today. 23:09:46 subtopic: https://github.com/w3c/vc-data-model/pull/1397 23:09:49 q+ 23:09:56 brent: Mike, you opened this one about an hour ago, I don't imagine people have had time to review. 23:09:56 ack selfissued 23:10:00 selfissued: Thank you. 23:10:28 selfissued: I was assigned an issue about working on correcting layering violations. I finally allocated a couple days time to work on VCDM. Yay -- to try and help us finish. 23:10:59 JoeAndrieu has joined #vcwg-special 23:11:10 selfissued: Most of the layering violations that were present that I found had to do with unlabeled uses of the `proof` property. Places where `proof` was present but it wasn't said that it was specific to certain securing mechanisms. I did some of this a while ago to sync with vc-jose-cose. 23:11:14 present+ 23:11:31 selfissued: This PR tries to be even handed around where `proof` is used and we say it's an example of using Data Integrity and where it wasn't needed I just removed it. 23:11:59 selfissued: There is another PR to go along with this in Data Integrity where I wanted to be really careful where if I removed anything in the VCDM PR that needed to be said in DI that I wanted to be sure that DI said it. 23:12:40 selfissued: The good news is that I read every line of my PR that was being removed and looked at DI and made sure that in almost all cases it was already said in DI. Only one sentence wasn't there. I am trying to be even-handed and positive and the point is to be agnostic to the securing mechanisms. 23:12:45 q+ 23:12:53 selfissued: I hope that this helps close the issue about having an even-handed verification method. 23:13:19 selfissued: Unless there are questions from people who have actually read it, I suggest we move on. I just wanted to flag to say we want people to read it because it gets us to closer to CR. 23:13:27 ack manu 23:13:33 brent: If anyone has read it please jump on the queue. 23:13:56 manu: I was able to read it before the call. Some of the changes in the text being made has already been removed in other PRs. 23:14:14 q+ 23:14:27 manu: That includes removing `proof` from some examples that has already been done in other PRs. That includes removing conformance statements around `proof` that are also gone. This PR would be removing things that are already taken care of elsewhere. 23:14:55 manu: The one problem is with removing `proof` as an extension point. There's a mismatch in understanding there I think. The `proof` property is not meant to be DI-only, but an extension point to be used by other securing mechanisms, some that may not be DI. 23:15:03 manu: That's my concern with the PR -- where it removes the extension point. 23:15:35 ack selfissued 23:15:43 manu: I don't think that was the intention of `proof` being an extension point. Otherwise, the PR is removing things that other PRs remove and that's fine. So I'm only worried about removing `proof` as an extension point. 23:15:50 selfissued: Glad to hear that other PRs are already handling much of this. 23:15:56 selfissued: We can all declare victory there. 23:16:22 selfissued: With respect to the extension point point ... I tried to be really judicious about whether there are examples using `proof` ... where there are examples I said this is an example that could be secured using DI. 23:16:56 selfissued: Quoting myself, something to the effect "`proof` can be included if specified for use by a securing mechanism." So any securing mechanism can be used, but it's not something you'd put in if the securing mechanism doesn't call it out. So I don't see it as needing to be a general extension point. 23:17:07 selfissued: Any securing mechanism can define an extension point and one of those can be `proof`. 23:17:13 selfissued: We can talk about that in the PR if you want. 23:17:26 brent: That's my recommendation, continue the conversation in the PR. It's been live for an hour, so get your reviews in. 23:17:40 selfissued: Live for an hour, but two days of work, had to read lots of text. 23:17:43 brent: Thank you, Mike. 23:17:46 subtopic: https://github.com/w3c/vc-data-model/pull/1396 23:18:00 q+ 23:18:05 brent: This PR renames "Controller Document" to "Entity Document", it has a good number of approvals and it does have request for changes from Joe. 23:18:10 ack manu 23:18:11 brent: Please jump on the queue. 23:18:40 manu: This PR came about because I'm trying to address Oliver's concerns around the spec and how issuer validation occurs and how you get the data for it -- and it meant talking about Controller Documents and connecting keys being used and so on. 23:19:15 manu: That means talking about that language around there and it was awkward; we've been using "Controller Document" for a while and it's not lining up quite right. This is a bikeshedding exercise so we don't want to spend too much time. 23:19:55 manu: The ActivityPub community uses Actor objects and uses or relies on this stuff -- and we have a separate spec for this and the name isn't quite right to match things up with other communities that want to share. 23:20:22 manu: I think the main point here is that "Controller Document" is a bit confusing and it's hard to see that a "controller document" and a "DID document" and an "actor object" refer to the same concept. 23:20:49 manu: This wouldn't be an issue if we didn't have to publish the controller document spec before we publish VCDM. Let's bikeshed in the PR, not today on the call. 23:20:56 brent: Thank you, Manu, thanks for the background. 23:20:59 q+ 23:21:05 ack JoeAndrieu 23:21:11 brent: Just noting, 4 approvals, request for changes from Joe to just keep calling it that. 23:21:58 JoeAndrieu: One is -- I think "Entity Document" loses the semantic relationship to the VC and secondly, I don't think DID documents are the same as Actor objects, they are not about the subject but about how to interact with its identifier. 23:22:16 JoeAndrieu: The binding between the identifier and the entity is the hard part in this work. A DID doc works even if you don't have that binding clear. 23:22:26 JoeAndrieu: I think the naming here can be confusing / conflating in the marketplace. 23:22:41 brent: Others make comments in the PR, please, thank you folks. 23:23:00 brent: I'm wondering if it makes sense, Manu, to talk about 1394 before something else. 23:23:12 manu: I'm fine with any order. There are 3-4 that all build on each other, but they change different things. 23:23:23 brent: I was seeing the building -- but if the directionality isn't vital we'll just go. 23:23:26 subtopic: https://github.com/w3c/vc-data-model/pull/1394 23:23:36 q+ 23:23:42 ack manu 23:23:42 brent: "Use new securing mechanism verify proof interface". This PR has been out for a day. 23:24:22 manu: This PR is an attempt -- at addressing the same concerns that Mike is trying to address in 1397. The way Jeffrey Yaskin and I are trying to address this is by saying the securing mechanisms must provide an interface that can give you back the secured data. 23:24:48 manu: This basically says that that interface is in place. It says that a securing mechanism must define that interface and you need to take these inputs and give back these outputs. 23:25:22 manu: Once that's in place, then we can address the layering violations -- it means we can drop a lot of language around processing `proof` and so on. I think it achieves what Mike's PR is also achieving, or part of it, by just using the interface. 23:25:29 andres has joined #vcwg-special 23:25:47 manu: By using the interface, we have gotten rid of mention of `proof` in the algorithms and the need to have a different verification mechanism algorithm. The interface makes it so we don't have to define that extra algorithm. 23:26:03 q+ 23:26:06 manu: It defines what the interface should be for the securing mechanisms and uses that in the verification algorithm and we have a simple, three step algorithm. 23:26:13 ack selfissued 23:26:14 brent: Please jump on the queue if you've read this PR. 23:26:34 selfissued: I will review it, I saw that it existed and skimmed it but decided to finish my PR first. 23:26:37 brent: Thank you, Mike. 23:26:39 q+ 23:26:40 brent: Any other comments? 23:26:44 ack manu 23:27:07 manu: Mike, when you're reviewing, keep in mind that this isn't an either-or -- it just simplifies a lot of language in your PR from there and we can see what deltas remain. 23:27:11 selfissued: Makes sense. 23:27:16 brent: Thank you both. 23:27:29 subtopic: https://github.com/w3c/vc-data-model/pull/1393 23:27:29 q+ 23:27:31 brent: "Clarify how issuer validation occurs". 23:27:35 ack manu 23:27:55 manu: This PR is an attempt at addressing Oliver's concern where Oliver is saying that the spec needs to be clear about how you verify that a VC came from a particular issuer. 23:28:03 manu: Some people in the group would argue that's validation. 23:28:46 manu: And that we don't do that and don't normatively specify that. So what I tried to do is ... we're now specifying an interface between the securing mechanisms and the VCDM verify algorithm -- and it now returns the controller and controller document. That gives you info you could use to check against the issuer. 23:29:11 manu: However, that's not the only way to do validation, you could also have a trust list with some keys and you could just trust that -- including the statements in the VC, including the issuer field. 23:29:42 manu: In that case the issuer isn't directly tied to the verification method and controller, etc. -- so I tried to address Oliver's concern to ensure the information is available if the issuer validation works one way. 23:30:04 manu: I added some non-normative language as well to help address Oliver's concerns. I don't know if these changes together address his concerns. 23:30:09 brent: Any comments on this PR? 23:30:46 brent: If all of these, if it's possible to find consensus, if the language needs tweaks or not, that is our goal. If you have comments to make please do or say the PR is great, etc. Let us know what we need to change for you if you need it. 23:30:50 subtopic: https://github.com/w3c/vc-data-model/pull/1392 23:30:53 present+ 23:31:01 q+ 23:31:02 brent: "Add requirement for securing mechanisms to have post-verification documentation". 23:31:06 ack manu 23:31:33 manu: This PR is an attempt to address a concern from Jeffrey Yaskin -- he wanted the securing mechanism specs to be very clear about what is and is not acceptable from a post-processing standpoint. 23:32:01 manu: This results in the interface we're defining -- the expectation is that there is an interface to ensure that only secured data is returned from the securing mechanism. 23:32:52 manu: In addition, Jeffrey wanted us to say that when you return that data back, the spec still says more about it. Such as, if you use VC-JOSE-COSE, the spec should say that that no JSON-LD processing was performed. 23:33:16 manu: A simpler exampler is ... "when you verify the data and you get back the secured data, you probably shouldn't sit on that data for a year and then use the data in a production setting without reverification". 23:33:29 manu: Something that says "don't use stale data that was only checked a year ago" 23:33:46 manu: So Jeffrey wants something like that -- this PR creates a requirement for the securing mechanism specs to be clear about those types of things. 23:33:47 brent: Thank you, Manu. 23:33:52 q+ 23:33:58 brent: Any comments on the PR? 23:34:04 ack selfissued 23:34:11 q+ 23:34:16 selfissued: Can you explain a little more by post-processing and why Jeffrey is worried about it? 23:34:18 ack manu 23:34:32 manu: Post-processing is Jeffrey ... as he's defined it ... is any processing after verification. 23:34:54 manu: You have a secured VC in, you run the verification algorithm, you get back the protected data and then everything after that is "post-processing". 23:35:00 selfissued: So using the claims would be post-processing. 23:35:05 selfissued: That seems like someone we'd want to have happen. 23:35:14 selfissued: I don't know what kind of negative post-processing he's concerned about. 23:35:34 manu: He links to two blog posts that talk about it -- and he had general uneasiness around using the claims in ways that they had not been intended to be used. 23:35:38 selfissued: I'll look at it. 23:35:42 manu: Thanks. 23:35:59 subtopic: https://github.com/w3c/vc-data-model/pull/1391 23:36:08 q+ 23:36:15 brent: "Clarify that ProblemDetails can be extended for any reason" 23:36:25 q- 23:36:33 brent: Nothing but approvals on this, it's pretty straightforward clarification that says you can use this even in production, etc. 23:36:40 brent: I expect this to be merged when the week is up. 23:36:54 subtopic: https://github.com/w3c/vc-data-model/pull/1390 23:37:13 brent: "Clarify that non-objects aren't allowed as VC graphs". This has a broad set of approvers, one request for changes. 23:37:32 brent: From Ted who is bringing editorial clarity with his suggestion. I expect this to be merged without trouble by the end of the week. 23:37:41 brent: Happy for comments if there are any. 23:37:52 brent: No one on the queue here either. 23:37:57 subtopic: https://github.com/w3c/vc-data-model/pull/1389 23:38:11 q+ 23:38:14 brent: Clarify that `proof` is an extension point. This PR is addressing issue 1316. I'm going to let Manu talk about it. 23:38:16 ack manu 23:38:54 manu: There was a part of #1316 that I thought we could potentially address before CR. This PR attempts to clarify that `proof` is an extension point and always has been, and DI uses it in a way that's compatible, but DI isn't the only way. Other specs can use it too. 23:39:03 manu: The only requirement is that you specify the `type` of the `proof`. 23:39:20 manu: The concern here is that if we make `proof` only about DI then it's bound explicitly to that and we wanted to avoid that. 23:39:43 manu: It makes some non-normative and small normative changes to clarify that. This PR also splits the securing mechanism section into two parts, one is to talk about securing mechanisms generally. 23:40:01 manu: We talk about envelope and embedded proofs. The separate part we create the `proof` extension section explicitly. 23:40:07 manu: It makes it much clearer that it's non-exclusive. 23:40:38 manu: There are some concerns that Ivan has and Mike has concerns, but we shouldn't look at this as an either-or with the PRs that Mike raised and this one. I think we can merge this one and Mike can come back in an make his edits. 23:41:00 manu: The key split here is that to talk about securing mechanisms and their specs wholly separately from the `proof` extension point. 23:41:01 q+ 23:41:03 brent: Thank you, Manu. 23:41:09 ack selfissued 23:41:17 q+ to talk next steps 23:41:27 q+ 23:41:43 selfissued: The strange thing I ran into when doing my PR was a statement that all embedded proofs must use the `proof` property. Which seems it's overly tying the hands of people writing proof mechanisms that we haven't thought of. 23:42:13 selfissued: You could easily imagine some future ZKP mechanism embedding a different identifier that's specific to the mechanism. It's fine for it to be an extension point, but it shouldn't be a mandatory one for all embedded proofs. I'll review with that hat on. 23:42:16 ack manu 23:42:31 manu: Totally agree, that is exactly the normative change I was hoping we could make. We're in agreement on that. 23:42:53 manu: The previous text forced anyone doing an embedded securing mechanism to utilize proof and we should relax that and +1 to that, Mike says he agrees. 23:42:59 selfissued: Ok, we're violently agreeing again, that's good news. 23:43:02 brent: Makes me happy. 23:43:26 subtopic: https://github.com/w3c/vc-data-model/pull/1387 23:43:34 brent: "Updating the vocab diagram". This is from Ivan. 23:43:42 brent: It's doing what it says. 23:43:47 brent: Happy for comments. 23:43:52 brent: I would appreciate review on it. 23:43:59 It's a pretty clean update -- not controversial, AFAICT 23:44:01 brent: I expect it to be merged. 23:44:22 brent: If you can review and approve that would be great, let us know about nits. 23:44:27 brent: Any comments before next steps? 23:44:28 q+ 23:44:34 ack manu 23:44:54 manu: Just before next steps, there is one post CR issue that I want to make sure we cover which is #1395 which adds a missing `digestMultibase` value to the base context. 23:45:02 subtopic: https://github.com/w3c/vc-data-model/pull/1395 23:45:43 manu: The current spec says "for `relatedResource`" that we're looking for feedback for `digestSri` or `digestMultibase`, in order for that to happen we have to enable one or the other or both. One was missing from the context. 23:46:11 manu: We have written text saying we expect the context to possibly change and can add/remove as we see fit. Just wanted people to see this. 23:46:18 brent: This PR seems straightforward to me. 23:46:21 brent: Any comments? 23:46:33 ack brent 23:46:33 brent, you wanted to talk next steps 23:46:39 brent: Next steps. 23:47:03 brent: Does the current set of before CR PRs reflect all of the changes that would be necessary to address all of the issues that we feel are necessary before CR. 23:47:04 q+ 23:47:09 ack manu 23:47:09 q+ to mention minor fix 23:47:33 manu: I believe this is all of them as long as we ensure no one raises a new issue, we should be ready for CR for VCDMv2. 23:47:39 scribe+ 23:47:40 ack dlongley 23:47:40 dlongley, you wanted to mention minor fix 23:48:21 dlongley: In looking at bitstring status list stuff, I noticed in that spec, it's important there and in other credential status things that the id value is optional. In VCDM, we have an inconsistency where it is required. We need a quick PR to say 'id' is optional for credentialStatus. 23:48:30 dlongley: I can file that issue when I'm done scribing. 23:48:46 brent: Excellent, any other concerns about work that needs to be done before we go into CR? 23:49:17 brent: Is the work in these PRs unclear to anyone? 23:49:46 brent: Having this set of PRs before us -- plus what Dave just mentioned -- would folks still be uncomfortable to say we're going to resolve to go into CR after we address these PRs? 23:50:00 brent: Now that we know what the set of changes is -- are we still premature or are we ready to resolve that on the call tomorrow? 23:50:01 q+ 23:50:03 q+ 23:50:10 ack manu 23:50:33 manu: I feel comfortable with it but mostly because I understand what all the PRs are doing. We certainly don't have more incoming, and the things we're trying to address in each of these PRs is pretty focused. 23:50:43 manu: I would be comfortable with that, but would appreciate hearing from others. 23:50:44 ack selfissued 23:50:52 selfissued: Yeah, I actually want to read all the PRs before making that call. 23:51:04 selfissued: There's kind of a presumption in there that we will get all these merged in some form and maybe we are. 23:51:14 selfissued: But sometimes people come out of the woodwork and say no -- talk to me tomorrow. 23:51:17 q+ on other specs we need to publish :) 23:51:18 brent: Thanks, Mik.e 23:51:21 q+ 23:51:24 ack manu 23:51:24 manu, you wanted to comment on other specs we need to publish :) 23:51:27 s/Mik\.e/Mike\./ 23:51:32 Topic: other business 23:52:03 manu: The other thing that makes this a bit more complex, is that we have to resolve to publish the VC specs dir and the "VC Controller Document" specifications as at least FPWD/NOTEs before we can take VCDM v2 into CR. 23:52:06 manu: That's the other thing to consider. 23:52:20 manu: That's another complexity there. 23:52:21 ack JoeAndrieu 23:52:37 JoeAndrieu: I just wanted to agree with Mike -- I feel there are too many moving parts to say we're all good just yet on those parts. 23:52:51 JoeAndrieu: Can you speak to the dynamics of pushing for that tomorrow? What's the advantage of having the resolution before publishing? 23:53:32 brent: There's a publishing moratorium going into effect tomorrow, no way to publish before that -- but if we resolve as a group to publish after these PRs -- then we can W3M eyes on things and avoid delays that might come up vs. doing it in January. 23:54:06 q+ 23:54:11 brent: The only real benefit is to put it front of people whose feedback we need before going into CR. I'm not pushing really hard, but if we're close enough -- and it sounds like now there are enough moving pieces that we wouldn't put a proposal before the group. 23:54:15 ack manu 23:54:20 brent: We're a couple months later than where we want to be already. 23:54:52 manu: One of the things ... decisions that might be easier tomorrow would be FPWD for the controller document spec. Bikeshedding that and coming to a resolution on what we'll publish could be a thing to do tomorrow. 23:54:58 q+ 23:55:02 manu: The easiest thing to do would be publishing VC specs dir, I think, resolving to do that. 23:55:10 manu: And we could put a focus on doing that tomorrow because we need those anyway. 23:55:14 ack selfissued 23:55:15 brent: Thanks, Manu. 23:55:36 manu: With respect to the controller document thing -- I'm in theory an editor, but I've prioritized the other stuff, I would like to actually read that spec and provide input before we publish it. 23:55:46 s/manu: With respect/selfissued: With respect/ 23:55:53 brent: Ok, we're not quite there, we'll get there. 23:55:58 brent: Thank you for all the work that has gone into these PRs. 23:56:09 brent: Please review as soon as you can, we will meet again tomorrow and discuss the open set of issues. 23:56:17 brent: That will be our last meeting until the new year. 23:56:23 brent: I look forward to seeing you all tomorrow. 23:56:53 zakim, who is here? 23:56:54 Present: brent, hsano, decentralgabe, dlongley, selfissued, JoeAndrieu, dlehn 23:56:55 On IRC I see andres, JoeAndrieu, selfissued, decentralgabe, hsano, RRSAgent, Zakim, brent, TallTed, dlehn, manu, seabass, joraboi445, SintayewGashaw, ivan, dlongley, stenr, 23:56:55 ... shigeya, bigbluehat, csarven 23:57:39 present+ manu, TallTed, andres 23:57:46 zakim, end the meeting 23:57:46 As of this point the attendees have been brent, hsano, decentralgabe, dlongley, selfissued, JoeAndrieu, dlehn, manu, TallTed, andres 23:57:48 RRSAgent, please draft minutes 23:57:49 I have made the request to generate https://www.w3.org/2023/12/19-vcwg-special-minutes.html Zakim 23:57:57 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 23:57:57 Zakim has left #vcwg-special 23:57:58 rrsagent, bye 23:57:58 I see no action items