Verifiable Credentials Working Group Telco — Minutes

Date: 2024-05-08

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Manu Sporny, Joe Andrieu, Ted Thibodeau Jr., Michael Jones, Kevin Dean, David Lehn, Dmitri Zagidulin, Benjamin Young, Phillip Long, Hiroyuki Sano, Steve McCown, David Chadwick, Gabe Cohen

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Dave Longley

Content:

Brent Zundel: Welcome to the VCWG weekly meeting, our agenda today consists of some announcements, controller document to FPWD, work item status updates, PRs, and issue processing.

Manu Sporny: This went out to the mailing list this morning, both the VCWG and the CCG mailing list.

Manu Sporny: California DMV Launches OpenCred with Support for Verifiable Credential based Driver’s Licenses: https://lists.w3.org/Archives/Public/public-credentials/2024May/0016.html.

Manu Sporny: The state of California, specifically the department of motor vehicles in CA, announced they are launching an open source platform that supports all the things this group is doing as well as OID4 and other API work.
… It’s a verifier.

Dmitri Zagidulin: @manu - what’s your sense regarding what sort of Known Issuer lists their platform will be running? (if it’s a general platform).

Manu Sporny: The big news is that CA DMV is issuing VC driver’s licenses now. It’s limited to 1.5M person pilot and there’s an expectation that after the pilot it will open to a broader population.
… It was announced last week that this is the first of multiple W3C VCs that CA will be issuing. There will be further announcements about what those will be as time rolls on. There is a general desire to align with what this work is doing, there is no request for a change in direction.
… There’s an expectation that CA DMV will align with the things that we are doing here, whatever becomes a REC they will be aligned with.
… There are 27M people in CA that hold DLs, the number from last week, half a million people today have a W3C VC in their wallet app.
… There is also announcement that CA DMV has integrated TruAge which uses W3C VCs into their CA DMV app.
… That’s an add on people can use there.
… This is a very big public deployment and big news for this community, focus is on rollout and to the larger citizenry.
… I do not speak for the state of CA, but as one of the organizations that worked on the open source platform, OpenCred, I’m happy to answer any questions if anyone has any.

Dmitri Zagidulin: Is it only verifier? And what trusted issuer lists or mechanism are they using if any?

Manu Sporny: It is only a verifier platform, it speaks CHAPI, VC API, OID4VP, it does standard verification over that.
… It has hooks to call out to other verifier platforms and potentially issuer platforms, but that would use the VC API to call out to remote issuance platforms.
… The known issuers are hard-coded for now. When you download and setup the opensource software, you specify the issuers that you trust.
… You put it in a config file.

Manu Sporny: There is plenty of room to improve that feature over time.

Michael Jones: First, congratulations. What is their plan, to the extent you understand it, for migrating to the new specs once they are recommendations and what securing mechanisms are they using?

Manu Sporny: They are migrating. This work started a long time ago, so they used VC-JWT 1.1, but this group has moved from that. It’s safe to say that anything this group puts out is on the table for what they end up migrating to.

Michael Jones: Thank you.

1. Controller Document FPWD.

Brent Zundel: We’re going to be getting the controller document into shape – as we had consensus for it to have everything from DI and VC-JOSE-COSE – so that’s what we’ll be doing to get all of those things in there.

Michael Jones: Having reviewed everything and comparing it to data integrity and vc jose cose, for the most part they were nearly identical, I’m hopeful that this is largely syntactic exercise and will be straightforward.

Manu Sporny: The controller document is not specific to VCs. I think Ivan would want us to pick a shortname that isn’t VC specific. That would be the only modification … to rename to “controller-document”.

Brent Zundel: How does that draft proposal look?

Dmitri Zagidulin: (yeah, it’s used for example for ActivityPub actor profiles, unrelated to VCs).

Michael Jones: Is it expected that other WGs would reference this, including the newly reformed DID WG?

Brent Zundel: short answer, yes.

Phillip Long: +1 to Manu’s simplification for the name of the Controller Document.

Brent Zundel: Short answer is “yes”, hopefully they will think it’s great.

Proposed resolution: Publish the Controller Document v1.0 specification (https://w3c.github.io/vc-controller-document/FPWD/2024-FPWD/) as a W3C First Public Working Draft with a target publication date of May 30th 2024 and a short name of controller-document. (Brent Zundel)

Brent Zundel: Any changes to new draft proposal? Seems good for folks?

Michael Jones: +1.

Manu Sporny: +1.

Brent Zundel: +1.

David Chadwick: +1.

Dave Longley: +1.

Dmitri Zagidulin: +1.

Phillip Long: =1.

Hiroyuki Sano: +1.

Phillip Long: +1.

Ted Thibodeau Jr.: +1.

Jennie Meier: +1.

Benjamin Young: +1.

David Lehn: +1.

Brent Zundel: There will be one more set of changes to bring it fully inline w/ Data Integrity, after that’s done, we should raise issues/PRs/modify it.
… There will be one more set of changes to bring it fully inline with DI – at which point doing PRs and raising issues and so on will begin.
… There was an email to the group indicating the expected timeline for this document, and for it to be published in time for it to be used for other docs, we’re going to be keeping a very tight schedule, everyone should keep that in mind.

Resolution #1: Publish the Controller Document v1.0 specification (https://w3c.github.io/vc-controller-document/FPWD/2024-FPWD/) as a W3C First Public Working Draft with a target publication date of May 30th 2024 and a short name of controller-document.

Michael Jones: I would characterize that we’re ready for issues/PRs.

Brent Zundel: I keep invitation open to manu to raise PR.
… I keep the invitation open to raise that PR if he sees it necessary to make sure it all lines up.

Manu Sporny: Things have changed. You’re largely right, Mike. Much of it is intact, but some algorithmic errors have been fixed and there’s a delta and we should bring it up to speed. It’s fine to raise issues because either the update will address them or we will have to do more PRs.
… I’m fine with raising issues now.
… When is it ok to raise the PR to move the rest of the DI stuff over?

Brent Zundel: In order for this to meet process, we need to bring it up to date w/ Data Integrity, at that point, we’ll follow normal operating mode.
… In order to meet the group consensus to create the document in the first place, it needs to be aligned with what’s in VC-JOSE-COSE and DI. I’m confident the former is covered but the not the latter, once the DI fixes are in that’s when the document is actually ready.
… That PR will go in as soon as it exists.

Michael Jones: I will review it when it’s in.

Manu Sporny: Ok, thanks.

2. Work Item Status Updates/PRs.

Brent Zundel: ok, moving on to work item status updates.
… For work items, if there are any issues that group should be aware of, PRs to review, please queue to share those.

Manu Sporny: So there’s obviously a set of new issues on the controller document that people should look at, I won’t go into any of those. For the data model, we have hit a snag on … for David Chadwick’s PR there are merge conflicts. Can you fix those before we merge?

David Chadwick: Yeah, sure.

2.1. Rework content integrity section based on @jyasskin’s feedback. (pr vc-data-model#1484)

See github pull request vc-data-model#1484.

Manu Sporny: The content integrity section has a number of objections on it. I presume we’ll talk about those at some point. The rest of the specs are doing their normal thing, that’s it from me.

Dmitri Zagidulin: do you have links to the content integrity objections?

See github pull request vc-data-model#1484.

Brent Zundel: We have some time to look at the content integrity PR.
… we have some time to look at that PR.

2.2. VC-JOSE-COSE.

Michael Jones: There is one PR that’s been filed to address issue manu raised on examples. I would ask people to let this one go through, it clears up attribution issue to separate whether we’re generating examples the right way from dealing w/ IPR.
… in fullness of time, we can/will update examples, Gabe will update that.
… I’d like to merge that one, few new issues for VC JOSE COSE. One from Martin Thomson noting showing headers in examples. Will need Gabe to look at this as well. I agree, we should be showing headers.
… I do have a procedural question, now that we’ve published a CR draft, can we merge stuff or do we mess something up?

Brent Zundel: You can merge whatever you need to into Candidate Recommendation Draft, as long as it doesn’t include normative changes, then we’re good to proceed. If there are normative changes, then before we move to PR, we will have to do another CR snapshot and get horizontal review on those changes.

Michael Jones: Intellectually, I understand, practically I don’t.

Brent Zundel: Merge whatever you need to merge. If there is a normative change, there should be a change log, if there are normative changes, then make sure we do CR Snapshot before we do PR.

Michael Jones: We can merge non-normative stuff into main?

Brent Zundel: yes.

2.3. Rework content integrity section based on @jyasskin’s feedback. (pr vc-data-model#1484)

See github pull request vc-data-model#1484.

Brent Zundel: This PR has had a number of comments on it, number of requests for changes, Manu could you talk us through it?
… Folks that would like to see changes, please do so.

Manu Sporny: This PR started out as a request from Jeffrey Yaskin to rewrite the content integrity section so that it matched the pattern of the other sections. This section was originally written by Mike Prorock, it was the first attempt at it and it went through a lot of churn and needed clean up.
… There were a number of things agreed to – as far as “please raise an issue noting X and Y” in the content integrity section. There was not agreement on the digest format we would use, but there was agreement that it would be between digestSRI and digestMultibase or both and leave it to implementers to decide on which ones to implement, if not both of them.
… This section was largely rewritten editorially, but there are objections to the way it was rewritten because we now mention both digestSRI and digestMultibase in the spec; one argument is that was always true, there was an issue marker in the spec that said we would rely on implementers to pick.
… The counterargument to that is that we never agreed to that but that’s challenged as well. Largely this is an editorial rewrite of the section and the thing that’s under contention is that digestMultibase is being specified more clearly based on the issue marker.
… I would be interested in hearing Mike’s concerns here and Jeffrey Yaskin has also jumped in with good questions we should answer and while we’re reworking the section we should address those. 80% are questions with answers, 20% we might want to discuss.

Michael Jones: Obviously, I’m the one who had made the point that we shouldn’t be normatively adding multibase to the VCDM spec since we have been careful to not include it before. I understand that there is an issue comment, but I’m not willing to elevate multibase beyond that issue comment.

David Chadwick: This new text should have removed the note, suggest removing that bit, rework editorial, and discuss later.

Manu Sporny: Yes, I think that the new text, actually, if you look at it carefully, the changes have been made, it’s clearly addressing Jeffrey’s comments. I think the new text on multibase isn’t replacing anything. We should have struck out the note. Then we can put that into a new PR and just work on that PR alone.

Brent Zundel: ok, so smaller more controversial bit to its own PR.

Dmitri Zagidulin: I’m curious, with regards to digestMultibase, since Mike’s objection seems to be primarily to the base encoding part, perhaps not the multihash aspect of it, I’m wondering if there’s still time or opportunity to change direction and require the base to be base64url and have it be a digest multihash, which provides significant size benefits over the digest SRI approach.
… Would Manu and other proponents consider pivoting and leaving the multihash aspect.

Manu Sporny: Sure. I think there’s a misunderstanding about what’s in the spec today. Today we normatively reference DI and VC-JOSE-COSE – because this group decided that because we’re publishing those we will normatively reference those from VCDM. As a result, we can pull in those normative things from those specs. If the concern is not defining them in VCDM, that’s not happening.
… We’re using it from the other specs. The more confusing thing is that we’re taking the definitions from DI – and moved them into the controller document. The thing with the normative definition for multibase is in the controller document. Now we’d have to ref the controller document from the VC data model. In the same way we ref SRI.
… We can’t just ref SRI, we have to specify a field and the format of that field and we have language around that. We have to define it somewhere. We have to figure out where to define it – we could define it in controller document, we could define it in VC-JOSE-COSE, we could define it in DI. I don’t have a strong feeling where it goes.
… But to use that feature we have to talk about it in the VCDM. I don’t quite understand what Mike’s objection – are you objecting to where it’s defined (it must be defined somewhere, but we have to normatively reference it to use it). I don’t really care where it’s defined but it has to be somewhere, the easiest place is in the VCDM, but we can put it in DI or somewhere else.
… We could throw it all in the controller document.

Brent Zundel: Just to summarize, currently the VCDM normatively references digestSRI and defines a profile of how we’re using it?

Manu Sporny: No, it references SRI, which is a web browser thing. We use a tiny piece of SRI but we can’t just do that. We have to define what the value is in the @context, its range, how it’s encoded, etc. SRI doesn’t do that, it’s targeted at browsers.
… We chose to do that work in VCDM, it’s a couple of sentences, it’s simple. But we have to do that for digestMultibase as well, but it’s already defined in DI and we can just ref it.

Brent Zundel: That was helpful.

Michael Jones: As Dmitri points out, the problem with digestMultibase is its dependent upon multibase, where inexplicably it defines something like 26 encodings for the same data, which is a travesty for interop.
… my objections are not about where this is defined, it’s to using it at all, because it hurts interop. I’m on public record about that.
… The multibase encoding is a failure to make a choice, we should steer clear of it.

Dmitri Zagidulin: @dlongley - but if we’re gonna use ‘u’ prefix only, why don’t we just specify that we’re using u, and save the extra character.

Dave Longley: 2nd Dmitri’s proposal to resolve this, to say that we only support the base64url prefix, which is the multibase prefix for base64url, nopad encoded, if we do that, then that gets us past the objection, then we get data savings, and so on.

Brent Zundel: proposal on the table is we specify which base and do that in this section of VCDM. Mike, would that address your objections?

Dmitri Zagidulin: I like Dave’s suggestion, but if we’re fixing that we’re just fixing base64url, and drop the ‘u’ and save ourselves an extra character.

Michael Jones: Well, Dmitri’s suggestion is rational, threw me off. In response to brent’s suggestion, I’m unwilling to define any form of digestMultibase in our core spec, I understand the irony, which defines this in controller document, and I do appreciate we got to compromise to DI where we don’t normatively ref 26 choices, but we decide w/ what Dmitri said, what choices we make, I do not know whether a form of digestMultibase is defined in controller document, if we’re going to define that w/ base64url encoding I’d do it there to keep everything together. The other question, I do support defining the fields necessary to use digestSRI in our spec in the Content Integrity section. Finally, I haven’t read Jeffrey’s comments, read them w/ eye, is he asking for Multibase to be specified. or is he asking unrelated editorial things?

Dave Longley: One of the advantages of using multibase is it introduces layers and a separation of concerns, so you can compress any multibase data regardless of whichever data is done, if you want to compress using CBOR-LD, it can do that sort of compression, or use tech that is not a VC, different choices on encoding, here in our group we can say base64url, no one has to go rewrite new tech, type is multibase, no new tech needs to be written to that particular field, that other tech continues to work, we get benefit that there is interop around that prefix, we get best of both worlds if we make that choice.

Dmitri Zagidulin: @dlongley - since that’s driven off of an RDF data type, can’t we define a base64url data type, and have processors just work off that/.

Dmitri Zagidulin: Dave’s point about CBOR-LD processors makes a lot of sense, since signal processors are working off of, RDF type multibase, why dont’ we define RDF type for base64url, same logic, same compression can be invoked?

Dmitri Zagidulin: but there’s like only 3-4 encodings realistically (base64url, base32lower, base32upper… like what else are you gonna use).

Dave Longley: What we’re suggesting now is a new RDF type for every encoding type, or we can re-use work out there, already implementations using that… if the world had decided to take a different approach, and communities were using RDF, then that might have worked, but there are separations of concerns, trying to re-use technologies, if we re-invent yet another way to do it, we’re less interoperable.
… simplest thing to do is take implementations already out there, will work w/ other tooling, we should invent fewer things, we should profile it down, it addresses Mike’s concern, they don’t have to use it either and will just work w/ VCs w/ one prefix.

Michael Jones: I guess I disagree with the characterization, it’s not inventing something, it’s something that’s been around for a decade and a half. If we need context and vocabulary term, let’s create it.

Michael Jones: Multiformats Considered Harmful https://self-issued.info/?p=2408.

Michael Jones: To Dave’s point, that’s what people have already used, that people chose to not make a choice doesn’t mean we should promulgate that or promote that.
… I did a blog post on the issue, I think multibase is an interop mistake and we should get rid of it, if we chose a prefix, we’re half getting rid of it, we’ll see how this works out.

Dave Longley: First to clarify, I didn’t mean to imply that base64url encoding , the alphabet is what’s being invented. We’d be inventing a new RDF type for a single base-encoding. Regarding failure to make a choice, depends on whether or not people feel things are equivalent. Community that built Multibase had their reasons. JWK allows different keys to be parameterized instead of saying one key format. We tried to re-use that work, and we’ve successfully been interoping with that technology. I would prefer us to not invent a new thing and cut it there because it seems like picking a prefix of U and putting it on there solves all the problems doesn’t solve… we’re building on other communities to greatest extend that we can profile those down, we should do that, instead of inventing something new.

Manu Sporny: There are a number of misconceptions around what multibase is including in that post that Mike wrote.
… I think we’re talking about reinventing the wheel here, we’re going to invent a single RDF type for a specific encoding of base64url-no-pad.
… That is hyper-specializing the encoding format when we don’t need to do that when we can just put a u on the front and say VCs use that and that addresses the “not making a choice” thing that Mike is concerned about.
… Why would people choose different base encodings? There are legitimate reasons for doing so. Base32, for example, when encoding in a QR format, compresses way better than base64url. There are technical reasons for it.
… You can’t think that all encodings work for all use cases. When you get into embedded and compression use cases, those encodings matter.
… There are totally valid reasons why people would want to use different base encodings and multibase understands that and that not every base encoding works everywhere. Base64 doesn’t work in URLs. That’s what Base64Url was created.
… There are many ways to send things and the ecosystem matters, it’s not a failure to decide. It’s understanding that the world is bigger than just us in this group and utilizing a way that lets you signal what base encoding is used so we can just use the multibase format across all the layers instead of having to reinvent the stuff at every layer.
… I appreciate you wrote that article but I think it’s off base and it’s not the reason multibase exists, it misses the point.

Brent Zundel: It sounds like, maybe overly optimistic, it sounds like we’re dancing around a middle ground that not everyone likes but we can live with, use base64url encoding, that’s the choice we’re making for multibase option for content integrity section.
… feels like we’re close there.

Dave Longley: the effect is larger than the invention of a tag itself.

Michael Jones: Mainly going to respond to Dave’s comment, defining base64url RDF type would be invention, perhaps, but it’s not a very big invention, it’s just tagging what this field uses. Creating the tag is perhaps an invention, but that’s a good thing, it let’s people know what choice was made.

Ted Thibodeau Jr.: I think a better title for that blog post would be “I Consider Multiformats Harmful” as it doesn’t seem to incorporate anyone else’s opinion.

Brent Zundel: please chime in in the PR, let’s explore that middle ground.

3. Resolutions