18:58:10 RRSAgent has joined #vcwg 18:58:10 logging to https://www.w3.org/2022/03/16-vcwg-irc 18:58:18 acoburn has joined #vcwg 18:58:18 Zakim has joined #vcwg 18:59:25 brentz has changed the topic to: Meeting Agenda 2022-03-16: https://www.w3.org/events/meetings/488e0b10-2126-4ebd-b898-9cc709b2b01e/20220316T150000#agenda 18:59:43 zakim, this is VCWG 18:59:43 got it, brentz 18:59:49 zakim, start the meeting 18:59:49 RRSAgent, make logs Public 18:59:50 please title this meeting ("meeting: ..."), brentz 19:00:09 meeting: Verifiable Credentials Working Group 19:00:35 chair: brentz 19:02:04 Orie has joined #vcwg 19:02:08 present+ 19:02:21 present+ 19:02:23 present+ 19:02:43 mprorock has joined #vcwg 19:03:08 present+ 19:03:26 present+ 19:04:06 scribe+ 19:04:19 Topic: agenda review 19:04:25 present+ 19:04:47 brentz: Agenda today is pretty straightforward, we'll do introductions, we'll talk about registries, talk briefly about data integrity and processing issues. 19:04:49 DavidC has joined #vcwg 19:04:49 present+ 19:04:53 present+ 19:05:24 brentz: Anyone who wants to add anything to the agenda? 19:05:31 topic: introductions 19:05:35 brentz: Ok, not hearing anything. Moving on. 19:05:54 brentz: Is anyone here joining for the first time or want to reintroduce? Please unmute and let us know who you are and what your IRC handle is. 19:06:03 selfissued has joined #vcwg 19:06:25 present+ 19:06:42 scott: This is Scott Heger. I'm with Identity Fusion. Based out of Florida, USA. We have employees around the country, some people in the UK, having been doing identity management/access for years, looking to expand into getting involved in the WG. 19:06:50 s/having been doing/have been doing/ 19:06:58 sheger has joined #vcwg 19:07:47 Songpi: I'm from China Academy of Info Tech. I've recently heard of this group and would like to follow up and do something to help you or myself. Our org hasn't joined the WG officially but would like to do that for my org pretty soon. Thank you. 19:07:59 brentz: Thank you for joining us, you are welcome to observe today. 19:08:14 brentz: First thing to talk about today is registries. 19:08:16 topic: VCWG Registries 19:08:34 brentz: We'll be focusing on, at first, on a couple of PRs just to see if we can come to agreement. If not, we'll end up closing them. 19:08:36 subtopic: https://github.com/w3c/vc-wg-charter/pull/99 19:08:43 brentz: First PR to look at is #99. 19:09:05 brentz: This PR takes the section where registries are listed and adds a non-exhaustive selection of registries the WG *may* wish to produce. 19:09:18 q+ 19:09:27 ack selfissued 19:09:28 brentz: We've had back and forth on this PR, pretty clear opposition from some folks who feel it's unnecessary. This is the conversation we're having now. 19:10:01 selfissued: I think that the registries that we create should come out of normative work that we do. They can organically evolve throughout the life of the WG. Thanks to Brent for already creating and merging the PR that says registries are in scope and we can decide what to add along the way. 19:10:20 q+ to say I didn't agree earlier, but now I do 19:10:23 selfissued: I think, if anything, a laundry list of registries could create problems and arguments in the group around not following the list. 19:10:26 ack brentz 19:10:26 brentz, you wanted to say I didn't agree earlier, but now I do 19:11:06 brentz: I didn't originally agree with you, Mike. I liked the symmetry of having the tables with the other sections. But having recently re-read the charter and to get to the registries section and just have a couple of lines there that says "we might do registries" is kind of a relief. 19:11:14 q+ 19:11:19 q+ 19:11:27 scribe+ 19:11:30 ack dlongley 19:11:41 TallTed has joined #vcwg 19:11:46 dlongley: I'm not speaking in favor of the list in this PR. but I would like to address people's concerns 19:12:03 ... I think what they're worried about - anything in that list is not available to be put into the WG in time. 19:12:13 ... but whatever's in that list, someone might say "well, that wasn't ever in scope" 19:12:27 ... but if we point to this GH issue, we can say, when we were making the decision, we were not ruling out anything in that list 19:12:37 ack Orie 19:12:46 Orie: I agree with Mike and Dave and Brent. 19:12:56 Songpu_Ai has joined #vcwg 19:13:26 Orie: Getting to that part of the charter is good without that list. We need to remember we might create a registry or we might not. That's what "we might do registries" means -- and it also means we might not. As long as we all agree that we might or might not do registries we're all fine. 19:13:51 Orie: The meeting minutes will show that we might do any number of registries, we might not -- we talked about all this. As long as that's well understood, we're good. 19:14:06 q? 19:15:21 brentz: So we have agreement that we probably shouldn't merge #99. So we will not. 19:15:26 brentz: Let's look at #100. 19:15:30 q+ 19:15:33 subtopic: https://github.com/w3c/vc-wg-charter/pull/100 19:15:49 brentz: PR 100 adds a possible set of input documents. 19:15:50 ack selfissued 19:15:57 selfissued: Can we close PR 99, having made a decision? 19:16:10 brentz: I was planning on closing it as soon as the minutes of today were recorded. 19:16:14 selfissued: That's acceptable. 19:16:49 selfissued: Having a list of input documents would take away from having a nice clear clause. 19:16:59 brentz: I agree, but the same decision would be made here. 19:17:07 q+ 19:17:11 ack Orie 19:17:24 Orie: I just have a question regarding why listing input documents is so contentious. 19:17:31 q+ 19:17:43 Orie: It seems we can all do registries or not do them. But it does seem like providing links to input documents seems better than not providing those. 19:17:56 Orie: Can we have a brief conversation around why we're blocking input documents when we might do something? 19:18:08 ack selfissued 19:18:25 markus_sabadello has joined #vcwg 19:18:51 q+ 19:19:07 ack markus_sabadello 19:19:15 selfissued: It's a fair question. It's my sense, looking at some of the input documents. The registries that are proposed are not structured the way I would structure it. Extensions are overly general. Extensions for VCs -- well there will be a lot of different possible registries. It would be better to have a fresh perspective. As I said in PR 99, we should organically create these. 19:19:22 q+ 19:19:25 q+ to not that the input documents have been created organically 19:19:40 q+ 19:19:58 markus_sabadello: I feel like we may or may not want to work on certain things. I don't see any downsides for listing existing documents and it's helpful to point to the existence of those. It doesn't mean that they have to be used, but I agree with Orie that it's better to mention them than to leave them out. 19:19:58 ack TallTed 19:20:29 +1 Ted 19:20:41 TallTed: In my world, input documents are things that we've learned from. Either we developed them and they are bad or they are good or whatever. It seems to me it's good to list input documents even if the plan is to make them worthless wrt what we develop. 19:20:46 +1 to Ted 19:20:48 TallTed: If we can't learn from past experience, what can we learn from? 19:20:50 +1 to Ted 19:21:04 ack Orie 19:21:04 Orie, you wanted to not that the input documents have been created organically 19:21:07 kristina has joined #vcwg 19:21:20 present+ 19:21:45 Orie: I think those input documents have evolved organically from those who have implemented version 1. Fully disclosure, I'm an author of a lot of input document / CCG draft things in this space. I can tell you w/ 100% certainty is that I've learned a lot here and many of those shouldn't have happened. 19:22:10 q+ to ask what if not a table? 19:22:29 Orie: To Ted's point -- acknowledging that we've learned from these things is important. Leaving them out is to bury our heads in the sand. We've learned a lot and a lot has been painful. Sometimes it's good to include an input document and then say that it represents the worst ideas we've had. 19:23:08 Orie: We're acknowledging that and we want to move on from it. I also agree with Mike in that we don't want to pour concrete around them. That's going to happen no matter what -- it's easier to talk about things if they are linked. 19:23:10 +1 to Orie 19:23:20 I think it's also OK to say "this is an example of something we are adamantly not going to make this time, in xyz ways" 19:23:23 +1 Orie 19:23:25 Orie: I would much rather acknowledge that the documents take us in a way we don't want to go as needed. 19:23:25 ack selfissued 19:23:30 +1 Orie 19:24:01 q+ 19:24:05 selfissued: To Ted's point and Orie's about learning from past work. I support that. I view that as orthogonal to listing them in the charter. There are a number of individuals like Orie, Ted, and Markus and others on this call that are familiar with them. That knowledge will not be lost and brought to the WG. 19:24:35 selfissued: Either positively or not. I don't think that having a laundry list of possible input documents really moves us forward. Once we have a working group rechartered, I'd be happy to have people submit pointers to that in meeting minutes or notes or drafts. 19:24:38 present+ 19:24:52 ack brentz 19:24:52 brentz, you wanted to ask what if not a table? 19:24:53 present+ 19:24:57 selfissued: A charter is a special thing, it does not have to have lists and lists of things. We're already pretty bloated, let's not do that anymore, please. 19:25:02 present+ 19:25:09 q+ 19:25:11 brentz: What if it was a list of links to follow and it wouldn't take up as much space. 19:25:28 selfissued: It's not the formatting that bothers me -- it's the presumption that these are the registries we want to create. 19:25:35 ack TallTed 19:25:35 the opposite is also true, the presumption that these ARE NOT the registries we want to create 19:25:40 selfissued: Let the registries evolve organically from the normative work we do together. 19:25:47 these registries have ALREADY evolved organically. 19:26:16 TallTed: The question comes to mind --- who is the charter for? It's for the Advisory Committee. It's not to benefit us to tell us what documents we've already worked on. It's to help other people benefit from work that's already been done. It's for them. 19:26:19 +1 Ted 19:26:24 q+ 19:26:30 TallTed: It's for people reading the charter to say "I don't know, what's this based on" so they can go look at the input documents. 19:26:31 ack DavidC 19:26:35 TallTed: And know what it's based on. 19:27:12 ack selfissued 19:27:16 DavidC: A number of people said this list contains both good and value examples. That means there's a value judgment. Anyone reading the list will not know what's good or bad. If we have the list and we put the value judgments, then people will get bogged down in the mud over those judgments. 19:27:36 selfissued: To the point about the Advisory Committee -- I can't imagine that the current wording that says that registries are in scope would be confusing. 19:28:07 selfissued: Having recently setup the new W3C registries policy they would be happy to seeing that. Listing things could be breaking into jail, generating questions that otherwise wouldn't occur. 19:28:11 agree regarding the "breaking into jail" bit. 19:28:12 topic: VCWG Charter Data Integrity 19:28:27 subtopic: https://github.com/w3c/vc-wg-charter/pull/96 19:29:16 brentz: This PR tries to make sure that the work taken on in the WG on data integrity can be more general than strictly VCs -- as long as we can still do VC stuff. This is just an attempt to make sure that the charter language isn't seen as overly binding. 19:29:26 q+ 19:29:27 brentz: So people can work on things that are the reason why they joined the group. 19:29:32 ack Orie 19:30:26 Orie: So I joined this group to do two things. The first is to make VCs work with JOSE, to work on VC-JWT as an envelope format for moving VCs around. I also joined this group because there's work I've been involved in for many years on linked data integrity, JSON-LD proofs, interesting things like selective disclosure with RDF normalization. 19:30:40 Orie: A lot of technology just like JWTs apply to more than VCs, this other tech also applies to more than VCs. 19:31:21 Orie: One of the interesting things is that JWTs are already an established standard and we acknowledge that they work for things other than VCs. I don't think anyone would accept language that says JWTs only work for VCs. We shouldn't accept any language for the same thing for the LD proofs. The alternative is to remove all of that from the WG because I'm here for JWTs too. 19:31:28 +1 Orie 19:31:48 q+ to channel Ivan 19:32:02 Orie: If we're doing something right, we should do it right. We should get over that fight before we do it. It's in scope for the charter. If it's removed we won't be having these discussions. I'm very strongly keeping it in and doing it right. It's one of the main reasons I joined the group. 19:32:03 ack brentz 19:32:03 brentz, you wanted to channel Ivan 19:32:43 brentz: To channel Ivan, he's raised a number of concerns -- that if we make these changes he's worried about arguments from other folks who killed the DI work when it was too general. He said he won't lay down in the road for this. 19:33:11 brentz: Looking at the changes, I believe some have been made. Are these changes sufficient to approve merging this PR, Mike? 19:33:14 q+ 19:33:21 brentz: And Kristina? 19:33:44 kristina: I've agreed to those suggestions, if those slight suggestions go in -- and I think Manu liked my comments. If he can make those changes, we'd be good to go. 19:33:45 ack selfissued 19:33:52 https://github.com/w3c/vc-wg-charter/pull/96/files 19:34:27 brentz: There are two suggestions in there are those the ones you're referring to, Kristina? 19:34:32 q+ 19:34:36 selfissued: I don't know what a well-bounded dataset is, so that's strange language. 19:34:42 ack Orie 19:34:45 selfissued: And I don't know what digital documents are. 19:35:02 Orie: I think you know what it is. 19:35:09 selfissued: It's not standard industry terminology. 19:35:36 Orie: Yes, it is. Industries understand what RDF is, what digital documents are (JSON is a digital document), lots of people know what these things are. These concepts are very understood by some folks and poorly understood by others. 19:35:45 selfissued: Say RDF if that's what you mean. 19:36:19 Orie: What we're talking about a form of proof around a structure of JSON. Sometimes it's JSON and sometimes it's canonicalized RDF. I would really prefer to not be in, in every call, we're talking about only doing vanilla JSON or only doing RDF dataset canonicalization. 19:36:31 Orie: The reality is that neither should be used for all use cases. That's a really bad idea. 19:37:07 um... most JSON can be printed (as can many if not all serializations of RDF) ... and most of the things that can be done with the digital version can be done with the physical, albeit by hand instead of by cpu... 19:37:24 Orie: The reason that there's objection and sensitivity here is because there seems to be some maneuvering around here. Not understanding RDF and objecting to it all the time is not a path forward. We should just get over that and acknowledge we're doing it together or we're not and removing it. I'd be ok with either approach. 19:37:33 Orie: But doing it and making it better means understanding it when you're objecting. 19:37:50 q+ 19:38:07 Orie: I'm going to be direct and tell Mike and Kristina to say that you're not familiar enough with the technology to object in the way that you are. You need to understand it first -- not just object first without understanding. That isn't helpful. 19:38:10 ack selfissued 19:38:14 Orie: I want us to focus on doing the remaining things well. 19:38:52 q+ 19:39:01 selfissued: I appreciate you being frank. I'm not criticizing the tech. That's a mischaracterization of my comments in the PR. I'm echoing Ivan's comments -- who understands W3C process -- that we'd be opening a pandora's box. I've made no comments on RDF/etc. 19:39:18 selfissued: I propose we defer this until Ivan says what he thinks here. 19:39:21 q+ 19:39:24 ack kristina 19:39:25 brentz: Ivan has said he will support whatever the group wants to do here. 19:40:18 kristina: I think there's some strong statements being made where we mischaracterize here. There's no objection to working on data integrity proofs here. If you look at the history at why it moved to this group -- it's because Ivan clearly elaborated in last week's call. When it was tried to define it generally there were a lot of questions. 19:40:50 kristina: Be it in cloud database like Google or in IOT for Microsoft. So this work moved here so we can have LD / data integrity proofs for VCs. I'm fully supportive of that. I wouldn't be here if I wasn't. 19:41:15 kristina: But saying we'd work on data integrity proofs on a group that just works on VCs beyond the VC use cases is too broad. 19:41:18 q+' 19:41:24 q+ 19:41:26 kristina: Drawing on what you said, Orie, saying we'll work on JWT for the OpenID spec would not make sense. 19:42:04 kristina: I think we should focus on getting data integrity proofs right for VCs first. If other people want to explore using DI proofs for other use cases they can do so, no one can stop them. 19:42:24 q+ 19:42:28 kristina: When thinking about the limited time this WG has -- we should focus on DI proofs for VCs. That's the context. 19:42:33 ack ' 19:42:39 kristina: If that doesn't correspond with your definition of getting them right, I don't know what to do. 19:42:39 ack markus_sabadello 19:42:45 Data integrity proofs are kindof required for VCs to work 19:43:06 "The group will focus on defining DI proofs to solve VC use cases" lanugage may help 19:43:11 q+ 19:43:21 q+ 19:43:54 markus_sabadello: I think kristina's comments / suggestions could be a good compromise could help. I like some of the suggestions to agree and state that this can be used for other things than VCs, but we think the scope of the group is to define it for VCs specifically. 19:43:56 +1 Markus 19:44:11 q- 19:44:16 brentz: If people think Ivan's language would get approved then we cna do that. 19:44:19 ack mprorock 19:44:23 present+ 19:44:23 the suggestions are going in the right direction. 19:45:13 mprorock: I think that language is an approvement, it's very helpful. I think for VCs to work for our customers, that JSON linked data aspect and semantic aspect is key. We need to sign over RDF data properties, if we can't clean that up and express that very directly. If we can't do that here we're going to create problems and that's not acceptable. 19:45:18 ack dlongley 19:45:30 dlongley: I do think there is some language we can agree to 19:45:53 ... that can reach a compromise here. We want to be very careful that the lang doesn't say 'someone else can define how to use Data Integrity Proofs elsewhere, but not here' 19:46:35 ... because that implies that another WG has to be created, to go and define how to do that 19:46:57 ... we should take the VC use cases into consideration, and those are the use cases that we work with, and make sure Data Integrity can be used with those use cases 19:47:17 ... and if somebody else finds Data Integrity useful for other use cases than VCs, then we've succeeded 19:47:21 ... the language needs to say: 19:47:31 ... "This WG is going to define Data Integrity Proof to solve VC use cases" 19:47:38 ... and if it solves other stuff and is generalized, that's great 19:47:48 +1 dlongley 19:47:51 ack selfissued 19:47:55 ... but if we explicitly say "but we're not going to define it for other things", that automatically implies that some other WG has to 19:48:28 selfissued: Brent, you can feel free to not answer this / not have the WG answer this. Before I was a member of the WG I suggested that the DI work should be done in its own WG. That was closed without action as far as I can tell. 19:49:06 selfissued: I know there is W3C background, I don't know what it is. The people in the connect working group so we created the JOSE WG and we did it. They are general purpose. It seems never non-orthogonal and weird and doing general RDF and signing. 19:49:09 q+ 19:49:12 Agree with Mike, we are doing both "general" and "specific" RDF Signing. 19:49:15 q+ 19:49:18 q- 19:49:18 ack dlongley 19:49:26 dlongley: the short answer to that, Mike, is - there are people in the RDF community 19:49:36 ... btw, this is where the "well-bounded" and "digital document" text comes from 19:49:38 * me thinks about academic vs practical folks involved in RDF 19:49:50 ... so, RDF community said "we can't use this text to sign everything on the internet" 19:50:05 ... because that's an unbounded set of data among all web pages 19:50:22 ... what we want to address is - you have a well-bounded single digital document, that's the use case we want to solve 19:50:31 ... that's incidentally what a VC is. but it applies to other things too 19:51:06 ... the only way we could easily move forward to this work, is to say - let's go to some group that has use cases that have to do with well-bounded documents, and work on data integrity there. so that's this WG 19:51:20 Topic: issues 19:51:23 brentz: Dave, if you wanted to do an alterate wording you can do that in the github issue. 19:51:36 https://github.com/w3c/vc-wg-charter/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Ahas-pr 19:52:02 subtopic: https://github.com/w3c/vc-wg-charter/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Ahas-pr 19:52:06 brentz: There are 10 open issues that have PRs. Let's talk about #81. 19:52:12 subtopic: https://github.com/w3c/vc-wg-charter/issues/81 19:52:33 q+ 19:52:39 ack kristina 19:53:09 kristina: I think it turned out that Tony's concern was that version 2 allows breaking changes to version 1. That it supersedes version 1 and we already have that in the charter and he's ok with that language. 19:53:10 q+ 19:53:14 kristina: So we can close that issue. 19:53:15 * me unfortunately has to run - really appreciate the time everyone 19:53:30 ack manu 19:53:51 q+ 19:53:57 manu: That does not mean that our intent is to completely break VCs. There should be an expectation that any backwards compatible or breaking change will undo significant scrutiny. 19:53:58 +1 manu - avoiding breaking changes if possible 19:54:00 ack kristina 19:54:12 kristina: I think the clarification here is that we will tell people to look at version 2 once published. 19:54:16 manu: Correct. 19:54:26 kristina: Yes, and we aren't actively trying to break version 1 if we can avoid it. 19:54:28 subtopic: https://github.com/w3c/vc-wg-charter/issues/68 19:54:42 q+ 19:54:49 brentz: Can anyone get on the queue to talk about this 19:54:50 ack manu 19:55:30 manu: Jeffery's point is that if we are going to define a field like "status" or whether a credential is revoked or suspended or whatever. If there's a protocol that goes along with the data model thing, define the protocol as well. To not do it is dangerous. I agree with him, but there are scoping decisions around not doing protocols yet. 19:55:53 manu: I think that's where we are. Jeffery would like us to put protocols in scope. They aren't in scope normatively, but to talk about non-normatively. That's the best the group can do now. 19:56:15 q+ 19:56:15 q+ 19:56:20 ack dlongley 19:56:43 sheger_ has joined #vcwg 19:56:47 dlongley: I'm trying to remember, with changes made to charter, we will take on work w/ CCG as we decide it'll become mature to do so, does this solve that problem? 19:56:50 q+ 19:56:52 ack kristina 19:57:21 kristina: Jeffery's initial comment, I think, was inspired by VC refresh. Where do we stand with that? Will we be normatively defining that if we want to or can we only just talk about it? 19:57:22 ack manu 19:58:03 manu: I think where we are, Kristina, if that we have been traditionally able to talk about the data model. It's possible in the VCWG 2 group we can talk about it but not normatively define it. It's part data model and part protocol. There's no input document listed for refresh or status list because we put protocol out of scope. 19:58:23 kristina: I think your comments that refresh is both on data model and protocol leaves it open as to what to do with it. 19:58:48 manu: Well, we can't work on the protocol parts, so we said that's out of scope. So the most we can do is publish that thing as a NOTE with data model and protocol. 19:59:00 q+ 19:59:13 ack DavidC 19:59:13 kristina: Ok, I think that's a good clarification. For documents that have partially protocols in them -- we can do the data model normatively and the protocol parts non-normatively. 19:59:40 DavidC: If we have anything in our data model that is a URL does that imply protocol and we've now excluded that? 19:59:51 brentz: No. We can point to normative documents for dealing with URLs, it's right over there. 20:00:02 brentz: We can't invent protocols. 20:00:17 brentz: Thank you all for coming today and for the progress we've made. 20:00:29 brentz: Please get into the issues we need to do more interweek processing in issues to get these cleared out. 20:00:40 brentz: Thanks all for being fantastic! 20:01:06 zakim, who is here? 20:01:06 Present: Orie, cel, acoburn, mprorock, dlongley, dmitriz_, brentz, DavidC, selfissued, kristina, juancaballero, shigeya, TallTed, manu 20:01:08 On IRC I see sheger_, kristina, markus_sabadello, Songpu_Ai, TallTed, selfissued, Orie, Zakim, acoburn, RRSAgent, brentz, dmitriz_, shigeya, tzviya, wayne_, dlehn_, dlongley, 20:01:08 ... gannan, adam, mlemweb, manu, dmitriz, collier, juancaballero, cel[m], dlehn, hadleybeeman, stonematt, bigbluehat, cel, rhiaro 20:01:33 present+ sheger_ 20:01:41 present+ Songpu_Ai 20:02:06 zakim, end the meeting 20:02:06 As of this point the attendees have been Orie, cel, acoburn, mprorock, dlongley, dmitriz_, brentz, DavidC, selfissued, kristina, juancaballero, shigeya, TallTed, manu, sheger_, 20:02:10 ... Songpu_Ai 20:02:10 RRSAgent, please draft minutes 20:02:10 I have made the request to generate https://www.w3.org/2022/03/16-vcwg-minutes.html Zakim 20:02:11 I am happy to have been of service, brentz; please remember to excuse RRSAgent. Goodbye 20:02:15 Zakim has left #vcwg 20:02:19 rrsagent, bye 20:02:19 I see no action items