Verifiable Credentials WG Telco — Minutes

Date: 2022-03-16

See also the Agenda and the IRC Log

Attendees

Present: Orie Steele, Charles Lehner, Aaron Coburn, Michael Prorock, Dave Longley, Dmitri Zagidulin, Brent Zundel, David Chadwick, Michael Jones, Scott Heger, Markus Sabadello, Ted Thibodeau Jr., Kristina Yasuda, Juan Caballero, Shigeya Suzuki, Manu Sporny

Regrets:

Guests: Song Pu Ai

Chair: Brent Zundel

Scribe(s): Dave Longley, Dmitri Zagidulin, Manu Sporny

Content:

1. agenda review.

Brent Zundel: Agenda today is pretty straightforward, we’ll do introductions, we’ll talk about registries, talk briefly about data integrity and processing issues.
… Anyone who wants to add anything to the agenda?.
… Ok, not hearing anything. Moving on.

2. introductions.

Brent Zundel: 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.

Scott Heger: 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, have been doing identity management/access for years, looking to expand into getting involved in the WG.

Song Pu Ai: 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.

Brent Zundel: Thank you for joining us, you are welcome to observe today.
… First thing to talk about today is registries.

3. VCWG Registries.

Brent Zundel: 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.

3.1. A non-exhaustive set of possible registries (pr vc-wg-charter#99)

See github pull request vc-wg-charter#99.

Brent Zundel: First PR to look at is #99.
… This PR takes the section where registries are listed and adds a non-exhaustive selection of registries the WG may wish to produce.
… 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.

Michael Jones: 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.
… I think, if anything, a laundry list of registries could create problems and arguments in the group around not following the list.

Brent Zundel: 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.

Dave Longley: I’m not speaking in favor of the list in this PR. but I would like to address people’s concerns.
… I think what they’re worried about - anything in that list is not available to be put into the WG in time.
… but whatever’s in that list, someone might say “well, that wasn’t ever in scope”.
… 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.

Orie Steele: I agree with Mike and Dave and Brent.
… 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.
… 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.

Brent Zundel: So we have agreement that we probably shouldn’t merge #99. So we will not.
… Let’s look at #100.

Michael Jones: Can we close PR 99, having made a decision?.

Brent Zundel: I was planning on closing it as soon as the minutes of today were recorded.

Michael Jones: That’s acceptable.

3.2. A non-exhaustive set of possible input documents for registries (pr vc-wg-charter#100)

See github pull request vc-wg-charter#100.

Brent Zundel: PR 100 adds a possible set of input documents.

Michael Jones: Having a list of input documents would take away from having a nice clear clause.

Brent Zundel: I agree, but the same decision would be made here.

Orie Steele: I just have a question regarding why listing input documents is so contentious.
… 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.
… Can we have a brief conversation around why we’re blocking input documents when we might do something?.

Michael Jones: 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.

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.

Ted Thibodeau Jr.: 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.

Michael Prorock: +1 Ted.

Markus Sabadello: +1 to Ted.

Ted Thibodeau Jr.: If we can’t learn from past experience, what can we learn from?.

Dave Longley: +1 to Ted.

Orie Steele: 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.
… 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.
… 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.

Dave Longley: +1 to Orie.

Ted Thibodeau Jr.: 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”.

Michael Prorock: +1 Orie.

Orie Steele: I would much rather acknowledge that the documents take us in a way we don’t want to go as needed.

Brent Zundel: +1 Orie.

Michael Jones: 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.
… 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.
… 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.

Brent Zundel: What if it was a list of links to follow and it wouldn’t take up as much space.

Michael Jones: It’s not the formatting that bothers me – it’s the presumption that these are the registries we want to create.
… Let the registries evolve organically from the normative work we do together.

Orie Steele: the opposite is also true, the presumption that these ARE NOT the registries we want to create.
these registries have ALREADY evolved organically.

Ted Thibodeau Jr.: 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.

Orie Steele: +1 Ted.

Ted Thibodeau Jr.: 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.
… And know what it’s based on.

David Chadwick: 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.

Michael Jones: 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.
… 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.

Orie Steele: agree regarding the “breaking into jail” bit.

3.3. Clarify that DI should focus on VCs but ensure generality. (pr vc-wg-charter#96)

See github pull request vc-wg-charter#96.

Brent Zundel: 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.
… So people can work on things that are the reason why they joined the group.

Orie Steele: 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.
… A lot of technology just like JWTs apply to more than VCs, this other tech also applies to more than VCs.
… 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.

Michael Prorock: +1 Orie.

Orie Steele: 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.

Brent Zundel: 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.
… Looking at the changes, I believe some have been made. Are these changes sufficient to approve merging this PR, Mike?.
… And Kristina?.

Kristina Yasuda: 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.

Orie Steele: https://github.com/w3c/vc-wg-charter/pull/96/files.

Brent Zundel: There are two suggestions in there are those the ones you’re referring to, Kristina?.

Michael Jones: I don’t know what a well-bounded dataset is, so that’s strange language.
… And I don’t know what digital documents are.

Orie Steele: I think you know what it is.

Michael Jones: It’s not standard industry terminology.

Orie Steele: 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.

Michael Jones: Say RDF if that’s what you mean.

Orie Steele: 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.
… The reality is that neither should be used for all use cases. That’s a really bad idea.

Ted Thibodeau Jr.: 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…

Orie Steele: 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.
… But doing it and making it better means understanding it when you’re objecting.
… 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.
… I want us to focus on doing the remaining things well.

Michael Jones: 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.
… I propose we defer this until Ivan says what he thinks here.

Brent Zundel: Ivan has said he will support whatever the group wants to do here.

Kristina Yasuda: 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.
… 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.
… 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.
… Drawing on what you said, Orie, saying we’ll work on JWT for the OpenID spec would not make sense.
… 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.
… When thinking about the limited time this WG has – we should focus on DI proofs for VCs. That’s the context.
… If that doesn’t correspond with your definition of getting them right, I don’t know what to do.

Michael Prorock: Data integrity proofs are kind of required for VCs to work.

Dave Longley: “The group will focus on defining DI proofs to solve VC use cases” language may help.

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.

Michael Prorock: +1 Markus.

Brent Zundel: If people think Ivan’s language would get approved then we can do that.

Orie Steele: the suggestions are going in the right direction.

Michael Prorock: 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.

Dave Longley: I do think there is some language we can agree to.
… 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’.
… because that implies that another WG has to be created, to go and define how to do that.
… 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.
… and if somebody else finds Data Integrity useful for other use cases than VCs, then we’ve succeeded.
… the language needs to say:
… “This WG is going to define Data Integrity Proof to solve VC use cases”.
… and if it solves other stuff and is generalized, that’s great.

Brent Zundel: +1 dlongley.

Dave Longley: 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.

Michael Jones: 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.
… 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.

Orie Steele: Agree with Mike, we are doing both “general” and “specific” RDF Signing.

Dave Longley: the short answer to that, Mike, is - there are people in the RDF community.
… btw, this is where the “well-bounded” and “digital document” text comes from.
… so, RDF community said “we can’t use this text to sign everything on the internet”.
… because that’s an unbounded set of data among all web pages.
… what we want to address is - you have a well-bounded single digital document, that’s the use case we want to solve.
… that’s incidentally what a VC is. but it applies to other things too.
… 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.

Brent Zundel: Dave, if you wanted to do an alternate wording you can do that in the github issue.

4. issues.

Brent Zundel: https://github.com/w3c/vc-wg-charter/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Ahas-pr.

Brent Zundel: There are 10 open issues that have PRs. Let’s talk about #81.

4.1. This should be LEVEL 2 not VERSION 2 (issue vc-wg-charter#81)

See github issue vc-wg-charter#81.

Kristina Yasuda: 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.
… So we can close that issue.

Manu Sporny: 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.

Michael Prorock: +1 manu - avoiding breaking changes if possible.

Kristina Yasuda: I think the clarification here is that we will tell people to look at version 2 once published.

Manu Sporny: Correct.

Kristina Yasuda: Yes, and we aren’t actively trying to break version 1 if we can avoid it.

4.2. Be clear that defining some fields means defining the ceremonies they point to (issue vc-wg-charter#68)

See github issue vc-wg-charter#68.

Brent Zundel: Can anyone get on the queue to talk about this.

Manu Sporny: 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.
… 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.

Dave Longley: 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?

Kristina Yasuda: 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?

Manu Sporny: 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.

Kristina Yasuda: I think your comments that refresh is both on data model and protocol leaves it open as to what to do with it.

Manu Sporny: 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.

Kristina Yasuda: 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.

David Chadwick: If we have anything in our data model that is a URL does that imply protocol and we’ve now excluded that?

Brent Zundel: No. We can point to normative documents for dealing with URLs, it’s right over there.
… We can’t invent protocols.
… Thank you all for coming today and for the progress we’ve made.
… Please get into the issues we need to do more inter-week processing in issues to get these cleared out.
… Thanks all for being fantastic!