Verifiable Credentials WG Telco — Minutes

Date: 2022-03-02

Attendees

Present: Brent Zundel, Charles Lehner, Manu Sporny, Aaron Coburn, Michael Prorock, Joe Andrieu, Dave Longley, Kristina Yasuda, Kevin Dean, Markus Sabadello, Orie Steele, Shigeya Suzuki, kdean, Juan Caballero, Ryan Grant

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Joe Andrieu, Manu Sporny

Brent Zundel: today’s agenda has changed slightly..
… the bulk of our time will be looking at issues..
… before that we’ll be looking at existing PRs.
… Any suggestions for items for the agenda?.

Manu Sporny: Maybe we could touch on timeline quickly..

Brent Zundel: sounds good..
… Let’s start off with introductions and re-introductions.
… Anyone new to the call?.

1. introductions.

Aaron Coburn: I work with Inrupt. I know some of you from other contexts. We’re doing a lot with VCs at the moment..

Brent Zundel: thank you.

Manu Sporny: Welcome to the group, Aaron! :).

Manu Sporny: Super excited that you’re here :).

2. announcement.

Brent Zundel: next a quick announcement.
… Our transition for candidate corrections to v1.1 has been approved. We did it!.

Manu Sporny: Hooray (and cheering).

3. charter timeline.

Brent Zundel: Moving forward let’s talk about timeline.
… Feel free to jump on queue.
… (Over the roar of muted cheering).

Brent Zundel: We want this to move forward as fast as possible, to present a charter to the AC.
… My goal is to get that done by the end of this month.
… Hop on the queue if you have questions or concerns.
… Seems like the consensus progress has been going well and that deadline looks reasonable.

Manu Sporny: +1 to “finished charter by end of month” being a realistic timeline.

4. VCWG Charter — PRs.

Brent Zundel: Here is a link to pull requests. Three..
… We’ll go through one at a time..

4.1. Complete the list of known cryptosuites of interest for standardization. (pr vc-wg-charter#93)

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

Brent Zundel: first one #93 List of cryptosuites for standardization.

Manu Sporny: this is in response to another request from Kristina in another PR. I did a full list and most of them got in, but these three..
… so I added this as things we might get to..
… The only difference is that these things have been done for a while..

Kristina Yasuda: Thanks, Manu..
… we need some time to review, but we appreciate the progress..

Brent Zundel: would anyone oppose merging this pull request?.

Kristina Yasuda: can I get time to review.

Brent Zundel: of course. So we’ll continue looking at that (no merge yet).

Kristina Yasuda: merging PR 93.

4.2. Add input documents column to conditional deliverables (pr vc-wg-charter#92)

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

Brent Zundel: Next up #92.
… adds an input documents to conditional deliverables.
… The names I made up on the spot, so we can bikeshed if desired.

Manu Sporny: the core thing that these PR does is add an inputs document column. To address what an input document is. This worked for the Registries PR.
… two concerns. there probably needs to be a general clean up re how we talk about these various deliverables.
… +1 to addition of column. -1 to some of the names.
… we need a discussion to figure out the names before we lock into that.

Brent Zundel: structurally, I think this addresses some of the concerns about the additional deliverables..

Joe Andrieu: -1 to merging without name fixing, but if acknowledged we could do that later.

Brent Zundel: anyone opposed to merging as is?

Manu Sporny: yes..

Joe Andrieu: me too.

4.3. Add Deliverables section on Registries (pr vc-wg-charter#85)

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

Brent Zundel: let’s look at #85.
… this adds deliverable section.

Manu Sporny: Sharing screen. This is the new section on registries..
… took description of registries from somewhere, then Jeffrey suggested we add a “based on” column.
… also, Mike Jones asked for a change in the name of the CCG registry. That happened historically, before W3C had a registry process..
… we can do more, we can do less, this is just a starting list.

Joe Andrieu: I want to reiterate - I expect I’m an outlier, so if I’m the only voice, don’t expect to uphold consensus. I think DID Spec Registries was a nightmare, I know W3C Registries process exists… contact information was added because I added to it, don’t think we’re mature enough to take on registry functions. It has been a nightmare, I would prefer an architecture that doesn’t presume centralized registries..

Michael Prorock: I want to +1 Joe on that..

Kevin Dean: I agree, building and deploying registries is a major undertaking, even for something that has a relatively small number of records..

Kevin Dean: +1 to Joe.

Kristina Yasuda: two things. One: Mike is on vacation. I have a message from him: On enumerating complete potential registries. He agrees with the text above the table. We’d work on the registries is good. More work to be done on enumerating the set..
… On the registry at W3C, that seems normal because the process is new. Registries have been proven powerful in other SDOs, so I suggest we keep the text that we will work on registries..
… We think we should have certain aspects of registries in charter..

Manu Sporny: I wanted to +1 Joe. I don’t think he’s alone. the DID Spec registries has been a nightmare..
… at the same time, I’m not going to -1 us working on registries..
… It is going to take an enormous amount of effort. But I think we should do it..
… It was used against us in the DID vote.
… The other statement about not enumerating registries is falling into the same trap is that people will argue that we shouldn’t do it because it’s not in the charter..
… We know we are going to have registries.
… This helps us later on when people object..

Kristina Yasuda: Because the working group can decide what work items it can pick up or not… that argument doesn’t stand..
… even if we do enumerate, even if we are to conclude specific concrete aspects of particular registries. we can’t really merge until those are addressed.

Manu Sporny: It’s true that it’s not a 100% guarantee, but I don’t think that’s what we’re looking for..

Joe Andrieu: I thought I was going to be a lone voice, but Manu, part of your argument was the assumption that we were going to create registries. Given my comment, I’m not sure that’s appropriate..

Brent Zundel: is it reasonable to produce a recommendation with intended extension points and not provide extension points for those to be registered.

Manu Sporny: yes, it is reasonable, that is what we intended to do with DID Core.
… in this case, i do think it is a useful thing.
… and I’ll be a part of that process.

Joe Andrieu: That was not part of the original intention of DID Core - a significant goal of DIDs and VCs is to be decentralized, compromise between JSON-LD and JSON was a false compromise, and led to expectation of centralized registries. Violates ethos of what we’re trying to do here. If we had managed DID Spec registries in compelling way, we failed to properly managed DID Spec registries, and I’m concerned about adding more registries w/o addressing.

Manu Sporny: that..

Orie Steele: +1 Joe, but not sure that the alternative is better..

Joe Andrieu: Understood, Orie, the alternatives are also challenging.

Kristina Yasuda: it’s not in scope of the charter to outline how we manage the registries. If we agree to potentially have them, that opens up the door to address the managing the registries problem.

Joe Andrieu: seems that a way to proceed may be to put in the charter that we “may” do this, but let the WG debate it..

Ryan Grant: +1.

Dave Longley: seems that a way to proceed may be to put in the charter that we “may” do this, but let the WG debate it..

Brent Zundel: +1 dave.

Joe Andrieu: +1 to dave.

Dave Longley: and +1 to joe’s concerns generally.

Manu Sporny: if I change the language, would that work?

Joe Andrieu: Good question, thinking….

Orie Steele: +1 Joe, i would stick to explict charter suggestions.

Joe Andrieu: Maybe, let’s look at it again in a week, I feel like there is a certain inertia/momentum. When you acknowledged with a -1, but said +1 anyway, we’re not thinking through these decisions, not convinced that’ll lead to the right outcome. Maybe your proposal is the best way forward, need time to think through that..

Dave Longley: i think it would be better to have time and space to litigate that in the group.

5. VCWG Charter — Issues.

Brent Zundel: See list of issues.

5.1. Each registry should include at least one standardized entry (issue vc-wg-charter#67)

See github issue vc-wg-charter#67.

Brent Zundel: on to #67.
… each registry should have at least one standardized entry.

Manu Sporny: Jeffrey is coming from a good place. If we have a registry, we should have at least one officially defined extension.
… points to the VC extension registry which is mostly empty.
… refresh methods, evidence methods, etc., we don’t have normative examples.
… people have also been using all of those, but none of them standardized.
… So, while I agree with Jeffrey’s intention, but there are concerns about registries.
… Is it just to document what “we” think is official, or to capture anything in the wild?.

Juan Caballero: can non-W3C members come to VCWG meetings to discuss proposals to the registry?

Manu Sporny: juancaballero, not really due to IPR issues….

Orie Steele: manu mentioned the obvious things this would put at risk: evidence, schemas, … my opinion is that these items don’t belong in the core suite.
… I think there is a lot ot be gained from taking a very sharp knife. We looked at this is the first version. And we saw that these extension points were a nightmare for interoperability.
… Why not let CCG continue incubating without requiring everyone to support these extension points.
… We should cut out anything that doesn’t have significant adoption.

Brent Zundel: I think this is a good idea for those properties that are normatively required..
… if its required, but there isn’t a definition, it is a problem.
… but for optional properties, I think it’s less of an issue.

Manu Sporny: +1 to what brent said. For things that are required, yes. But not for refresh, evidence, TOS, etc..

Orie Steele: +1 manu, everything manu just said is optional..

Manu Sporny: orie, the danger in what you said is that then there are no ways to extend.
… that’s my concern. It took 10 years for SVG to be standardized and it kept getting panned because it wasn’t a standard yet..
… It’s premature to say these things are not useful. I know that all of these fields are being used in the wild..
… I would be fairly big -1 to remove them at this point.

Orie Steele: I am in favor of experiments… I am not in favor of experiments in the core spec..

Joe Andrieu: I want to echo the sentiment, Manu summed it up - options vs. required that Brent introduced is vital. My concern, we have to experiment, we don’t know what’s going to work, we’re all still learning. All specs in this area has acknowledged that fact. We’re not building a single monolithic system that everyone wants. There are pieces here that create value, but we don’t know what all the pieces need to be..
… I know I’ve pointed out a number of these properties to my clients, the extension points are vital to having a standard that’s relevant both today and tomorrow..

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

See github issue vc-wg-charter#81.

Brent Zundel: next issue #81.
… rather than v2, perhaps we should call it level 2 to comply with other W3C recommendations.

Manu Sporny: there’s no rule in here that says use level 2 instead of version 2. It is confusing.

Joe Andrieu: -1 on this issue.

Joe Andrieu: Level 2 to me, implied semantics, seems to me that Level 1 is still valid. It doesn’t convey we’re “updating that first version to newer version, where not all of the first thing might be valid anymore.”.

Juan Caballero: “An earlier version of EPUB (EPUB 3.0.1) was published as an ISO standard ISO/IEC TS 30135:2014 (parts 1-7). This Working Group and ISO may consider updating that ISO specification once the new Recommendations are published…” Additionally, there are currently activities within ISO/IEC JTC 001/SC34 on specifications that rely on earlier versions of EPUB (e.g., EPUB Preservation, EPUB Accessibility). A liaison has to be maintained on, possibly, updating those ISO specifications to the latest versions of EPUB 3, specified by this Working Group.”

Juan Caballero: (^from Iván’s example).

5.3. Add JwtProof2020 to the charter (issue vc-wg-charter#84)

See github issue vc-wg-charter#84.

Brent Zundel: next up #84.
… add JwtProof2020 to charter.

Orie Steele: There is an implementation of jwt-vc at DIF that is really an “internal” format, but it looks like an external one..
… so I raised this to help resolve the issues. We also want to be able to find JWTs in a database.
… we could say this is not our business, but clearly the folks behind JWT-proof thought it might be useful to be explicit.

Manu Sporny: A couple ways to address Orie’s issues. If folks want to talk about storage, maybe that can be done in the VC-JWT spec.
… the way the spec is constructed now feels like noise. It’d probably be better to just shut that down..
… I hesitate to pull it in when it isn’t really a cryptosuite.
… My suggestion is DIF should shut it down or rename it to remove the confusion.
… Not likely effective to depend on DIF to fix this.

Dave Longley: btw, ignoring how people may use VCs entirely can lead to mistakes wrt priority of constituencies (e.g., making it easy for someone to write a spec or implement signing/verifying a VC, but harder for end users to use the verified data in a variety of ways).

Juan Caballero: there is no ongoing work to shut down.

Orie Steele: you got part of it right, but one of the suggestions is the JWT part of the spec could comment on this to make it intelligible..

Juan Caballero: it’s a historical document.

Manu Sporny: it should be marked as such.

Juan Caballero: it should!.

Manu Sporny: W3C got in serious trouble over the years by not marking old documents as historical or rescinded. and thus had to put that process in place..

Orie Steele: So maybe we talk about this as an implementation guide. That kind of comment, clarifying how not to do what the DIF spec is interpreted as..

Orie Steele: the best thing we could do is to comment on this format in a way that instructs and encourages contribution and removes security risks.
… I suggest that we do that in the JWT cryptosuite.
… alternatively we could take a harsh stance and decide we recommend AGAINST the DIF approach. In any case, we need to talk about storing JWTs to avoid the security issues from misunderstanding.

Brent Zundel: I appreciate the conversation. My read of the charter doesn’t prohibit what has been proposed, so are we asking for changes to the charter, or just anchoring future discussions..

Manu Sporny: I won’t be opposed to a sentence in the charter saying that we are going to talk about storage formats..
… but we probably don’t need it. The desire is on record and we can refer back to this discussion..
… DIF needs to mark such specs as historical. W3C learned this the hard way and we need DIF to up its process to do something similar.

Orie Steele: FWIW I would avoid looking at DIF documents in any way other than you look at CCG docs..

Juan Caballero: +1.

Orie Steele: +1.

Michael Prorock: Adding an explicit sentence just to clarify… maybe not “storage formats” per se, but we do need to clarify how JWTs and VCs relate and the implications of that.
… “What happens if you do X”.
… just because JWTs are out there, widely used for very similar operations..
… Clarifying how these things actually work and what you should do there is valuable for us to tackle.

Juan Caballero: to mike’s point about documenting the JWT<—>VC relationship in the JSON section of the spec2.0.

Orie Steele: what Mike said that I think is the important highlight for interoperability, there’s the credential and there is a verifiable credential..
… in v1 the credential is JSON with a separate proof. The JWT-proof breaks that model, but it does it for a good reason, so we have to consider that usage (querying in a data store).

Dave Longley: +1 to the idea that we need to consider how VCs will be used, stored, etc. – vs. only focusing on integrity proofs directly..

Orie Steele: in some ways this could be solved by the VC-JWT clarifying its credential format is different from VCs..
… I do think the charter should clarify we will normatively defined what a credential and verifiable credential in the context of a VC-JWT.
… If we are good about using those terms correctly and educating those who use it poorly, everyone is going to be better off.
… we can’t allow people to refer to other things as if they were the normatively defined thing. We should address the difference between embedded and separated proofs..
… Big +1 to Mike’s comment.

Brent Zundel: would you be willing to raise a PR so we can continue the conversation more concretely..

Orie Steele: I would if we have engagement on the issue itself. Once we get that, i’ll draft a PR.

5.4. Environmental, Ethical and Social Implications of the Work (issue vc-wg-charter#89)

See github issue vc-wg-charter#89.

Brent Zundel: issue #89.

Orie Steele: the tech we are working on here has ethical consequences, from expensive processes to digital human rights like freedom of movement, which can be impacted by adoption of VCs at scale.
… what I don’t want to do is get to the end of the process and have people oppose it then.

Manu Sporny: I’m concerned that this is like a honey pot for endless discussions of ramifications of technology.
… I would be fine to say we are going to publish a note.

Manu Sporny: that note can be a centralized focus for those interested. but if we start taking up main call time, that would be a negative.

Orie Steele: previously a “note” was no sufficient to avoid FOs..

Joe Andrieu: I’m pretty opposed to this approach at all, it’s creeping Nanny-state-ism. People will use it to attack things they don’t like. That’s not our role here. Our role is to step outside the “morality matrix”. Our job is to put options on the table..
… If we need to start the fight here, the EWP work is a mistake. That whole framework that the W3C should be the morality police is misguided. I don’t think this is the right way to handle these problems..