Verifiable Credentials Working Group Telco — Minutes

Date: 2022-08-24

Attendees

Present: Ivan Herman, Kristina Yasuda, Kevin Dean, Brent Zundel, Dmitri Zagidulin, Shigeya Suzuki, Dave Longley, Justin Richer, Phil Archer, Marty Reed, Kerri Lemoie, Andrew Whitehead, Snorre Lothar von Gohren Edwin, Sebastian Elfors, Michael Jones, Manu Sporny, Michael Prorock, Will Abramson, Gabe Cohen, Joe Andrieu, Oliver Terbu, Shawn Butterfield, Ted Thibodeau Jr.

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Dave Longley, Manu Sporny

Kristina Yasuda: The agenda for today, first we’d like to talk about the agenda for the TPAC F2F hybrid meeting.
… Brent and I put together a draft agenda which is looking pretty holistic and thorough, but we’re looking for feedback, we’ll be sending that out shortly.
… Then we’d like to continue discussing the issues.
… Any reintroductions?

Snorre Lothar von Gohren Edwin: I work for Diwala that is a company that works with VCs in Africa. I’m an invited expert trying to figure out how to contribute the best way possible. I’d like to participate more in the details more in the specification.

Kristina Yasuda: Anyone else?

Manu Sporny: Just real quick – another agenda item, I’d like to do at least a ping on a couple of PRs. 5-10 minutes tops.

1. TPAC agenda.

Kristina Yasuda: See preliminary TPAC agenda.

Kristina Yasuda: Let me quickly walk through. On the agenda list, we have a view of both days, Thursday and Friday, so 8am Vancouver time is the start time.
… We’ll do introductions, timelines and deliverables. We’ll be doing a hybrid meeting so we’ll want to make sure that people joining remotely feel comfortable as well.
… Then we wanted to start with the use cases conversation. Then focusing on lessons learned from version 1 [and so on per the spreadsheet].
… We’ll make sure we have breaks, W3C wants us to be strict about breaks.
… We’ll talk after the break about how V1 is structured and talk about how we have multiple documents worked on the same time. We’ll want to make sure everyone in the WG has a clear view of how the components fit together. We have agreement at a high level but the devil is in the details and we’d like to tackle that in the in person meeting.
… We want that to be beneficial for the editors of all documents.
… Then we’ll have lunch and we’ll have the joint WG meeting and talking about stream lining cryptosuites.
… We’ll be talking about Data Integrity, led by Manu there and then another break. We’re hoping to finish up the first day talking about registries. We confirmed with Sam Smith who will be joining remote to talk about ACDC.

Michael Jones: What is ACDC?

Kristina Yasuda: We’ll end the first day at 5pm. Starting day 2 again at 8am. We’ll be talking about holder bindings, led by Oliver and we are also confirming with others for joining remotely.
… [Other items from spreadsheet mentioned].
… We’ll have lunch and then talk about multi-party and then another break, and then JSON schemas, etc. We also left 75 minutes to allow for additional topics to come up and discuss and we should be able to accommodate one or two.

Manu Sporny: +1 to the agenda, in general.

Michael Jones: Back in black?

Phil Archer: +1 for the agenda.

Brent Zundel: If no one has any comments about the agenda specifically, I’d like to talk about Thursday evening dinner.

Kristina Yasuda: Yes, go ahead.

Michael Jones: Where is the attendees tab? Is there a URL?

Kristina Yasuda: yes, the tab is next to the agenda in the same excel sheet.

Ivan Herman: See TPAC home page with further information.

Brent Zundel: I’m doing my darnedest to get a sponsor. If anyone will be there, please fill out the attendees tab on the spreadsheet so we can be as inclusive to everyone’s dietary needs. Based on who is signed up now … we’re going to a steakhouse! We want to encourage everyone who is joining Thursday hopefully to a sponsored dinner to let us know their food preferences.

Kristina Yasuda: Any feedback or comments on the agenda?

Dave Longley: None.

Kristina Yasuda: Brent and I will be reaching out to people who will be leading discussions to get slides so we can compile a single slide deck.
… If you can collaborate there that would be appreciated.

2. PRs.

Manu Sporny: A couple of PRs to get moving, just one we really need to talk about.

2.1. Specify the draft Verifiable Credentials v2.0 context. (pr vc-data-model#905)

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

Manu Sporny: PR #905 establishes a draft v2 context. There was some discussion on date properties and those have been stripped out for now to be discussed in an issue.
… The only person that needs to re-review right now, I think, is Mike Jones. I removed what was under debate to an issue until the group decides what people want to do with it. I’m just calling for any objections, the PR is ready to go.

Kristina Yasuda: Thanks, Manu.

Sebastian Elfors: Here’s a combined ask related to the FPWD: We have it on the agenda on TPAC and there is an open issue as well. Kristina and I have been commented on it a bit, should we take the opportunity to elaborate on that and come up with an accommodation for Presentation Exchange prior to the TPAC meeting.

Kristina Yasuda: Are you asking for time to discuss it today or a general heads up?

Sebastian Elfors: It’s a heads up really, we can take it offline if you prefer, you and I are active in the particular issue. Since we have this issue open, potentially we could prepare this a bit more and present it at TPAC.

Kristina Yasuda: Ok, great, I’d like to collate the conversation at TPAC and it’s a good heads up to the group. We have time we can touch on it today and if not we can put it on the agenda for upcoming meetings. I wanted to go back to Manu’s question about the PR.

Kristina Yasuda: the issue Sebastian mentioned: https://github.com/w3c/vc-data-model/issues/908.

Ivan Herman: I had some issues that you put comments on ~15 minutes ago. That’s fine, but I would like you to look at the corresponding issue I had in #916, because I’d like to have the vocabulary document put in before this goes to merge. I have some basic questions I need answered.

Manu Sporny: Are you saying to block the PR until that’s ready?

Ivan Herman: No, it’s already ok if it’s not blocked, these things are evolving and I’d prefer these two things to run more or less in sync.

Michael Jones: I approved https://github.com/w3c/vc-data-model/pull/905#pullrequestreview-1084010675.

Manu Sporny: Got it, I’ll look and respond today.

Kristina Yasuda: It looks like Mike has approved the PR, it looks like the PR should be good to go.

Manu Sporny: Ok, thanks, that sounds great.

2.2. added awoie to editor’s list (pr vc-data-model#911)

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

Manu Sporny: This next one is adding Oliver to the document as an editor. This decision was made and I’m just going to merge that if there are no objections, this is just a heads up to the group.

Brent Zundel: +1 to merge 911.

2.3. data integrity pull requests.

Manu Sporny: See Data integrity pull requests.

Manu Sporny: Finally, there are a number of PRs on the VC Data Integrity spec that the group should be aware of. We’re trying to document the design criteria that went into the specification. There are a number of PRs about that. I’ve asked for review, but people should be aware that these will start getting merged this weekend.
… If there are objections we will of course wait to get things addressed.
… If you’re interested in the Data Integrity work please take a look at those PRs.

3. issues.

Kristina Yasuda: See issues to be discussed.

3.1. [Tracking Issue - Proposed Corrections Feedback] URL to URI (issue vc-data-model#862)

See github issue vc-data-model#862.

Kristina Yasuda: The top one we have is issue #862.
… This is a request to fix the mixed use of URLs and URIs – and I believe this has been done. The issue was closed once and then re-opened because there was going to be follow-on work in V2.

Brent Zundel: As I recall, we made some editorial changes in V1.1 where there is a distinction between URI and URL. I believe there are still some outstanding changes that could be made in V2 to just change everything from URL to URI. I think that was the consensus of the group at the time, whether that’s the consensus now is up to this group.
… There’s some identifiers that are still identified as URLs and others as URIs and this issue says it should be unified.

Michael Jones: For context, in IETF specs, URI is preferred over URL.

Manu Sporny: I’m just speaking to the concept that we would unify these. I think we carefully picked which of these IDs are URIs and which are URLs. The ones that are expected to be derefenced are URLs and the URIs do not have that requirement.
… I think we were very careful about making the distinction between the two. I think I’m a -1 to just making all of them a URI or a URL because we put considerable thought into which is which.

Ivan Herman: I am fine with what you say, but I’m looking at the references in the data model spec, there is a reference to the URI which is the RFC, there is no reference to URL. In practice, almost all the new specs in W3C refer to the WHATWG spec as the reference for URL.

Michael Jones: For instance, in OAuth [RFC 6749], it’s a redirect_uri, even though it’s obviously dereferencable.

Ivan Herman: The WHATWG spec is hard to read but it encompasses lots of things and also handles URIs in some sense. We do need a proper reference to see what URL we are talking about.

Manu Sporny: +1 for updating the reference, that’s something we meant to do and we did mean to use the new WHATWG spec.

Kristina Yasuda: Do you want to do that within this issue?
… We could try to get a concrete proposal.

Michael Prorock: +1 reference and use that spec as the baseline.

Manu Sporny: How about the group says we should change the reference to WHATWG URL – is that what the group wants?

Kristina Yasuda: Is there agreement in the group to do that and to reference the WHATWG URL spec? Is there anything else that needs to be done?

Dmitri Zagidulin: I’d like to offer an alternative proposal to go into the issue / PRs. We change it uniformly to URI but note the places where we expect dereferencing. So we don’t rely on an obscure definition and we just say it explicitly.

Kristina Yasuda: I think you’re suggesting something similar to what Mike Jones has put in the chat.

Manu Sporny: hrm, -1 to that… the difference between URI and URL is dereferenceability.

Michael Jones: I agree with Dmitrii’s proposal.

Kristina Yasuda: I don’t think we have consensus. I’d like to propose for people to continue conversation in the issue.

Ivan Herman: If we have dereferencable things that we use all over the place we will get comments from the TAG and other places that we should use the WHATWG URL spec. The overall point of that spec was to unify around dereferencable things.
… If that’s the goal it would have to be URL.

Kerri Lemoie: Link to URL spec?

Ivan Herman: See WhatWG URL spec.

Kerri Lemoie: Thanks.

Michael Prorock: I just put a PR that’s up on data integrity where manu and I and others dug in deep and put URL where it’s dereferencable and it became apparent that we kinda have to go with the WHATWG URL spec. As much of a mess that spec is, it covers all of the various issues we want to cover.
… I’m pretty firmly on “let’s point to WHATWG URL spec and call it a day”.

Michael Jones: In IETF all the protocol identifiers use URI. In the text description, if something is a URL, it’s reasonable to say …
… … where URIs are dereferencable they can and do say URL.

Manu Sporny: See WhatWG’s view on URLs vs URIs.

Michael Prorock: +1 manu.

Ivan Herman: +1 to manu.

Manu Sporny: To make this even more complicated, the WHATWG URL spec, firmly asserts that they are supplanting the term URI. The browser manufacturers and a variety of software developers agree and this is sort of a lost battle. They want to use the term URL for everything.
… Folks in this group might not be aware of the long history here.
… Another argument here – and I’m not arguing for this – there are a number of alternatives: Mike Jones says call them all URI and some can be dereferenced, we use URI in some places and URL in others, or we use WHATWG and “URL” everywhere.
… All of these options have pros and cons.

Michael Jones: What a mess!.

Michael Prorock: +1 selfissued - super mess.

Kerri Lemoie: If browsers are adopting URL everywhere, that may be the easiest & most understandable approach in the longterm.

Phil Archer: I’ve been aware of this for a while now – and I say you can call it whatever you want and I call it a URI – maybe not helpful. At GS1 we use deliberately use URI because the identifier is independent of the domain name. Maybe a good or bad choice, but we say things are a URI that can also be a URL and you can do things online with it. I’m afraid that once I retire the phrase URI is going to disappear.

Kristina Yasuda: Could you in your PR make it really clear that we’re using WHATWG URL but … the thing is a URI? Is there a good middle-ground?
… Are there any objections for Manu doing this PR?
… I think, Manu, if you could try to reflect people’s concern in the PR and if there are no objections we can come back to the issues conversation.
… Does that sound good?

Manu Sporny: +1.

3.2. VPs and timestamps? (issue vc-data-model#877)

See github issue vc-data-model#877.

Kristina Yasuda: So the next issue … the ask was, could we have a timestamp in VP to prevent replay attacks?
… I think Manu and David Chadwick have been talking about there already being something in VP there.

Manu Sporny: I think we already cover this concept around timestamp / of when a VP is created. JWTs have multiple ways of expressing a datetime and DI also has that as well.
… I don’t remember if they were asking about validUntil/validFrom or something like that on the presentation itself. I don’t think Lee and David were asking for that. I think timestamp verification has to do with protection around the VP and both JWT and DI have protections for that. I don’t think there’s anything to do here.

Kristina Yasuda: I think I agree. Any objections to mark this pending closed based on Manu’s explanation?

Michael Jones: https://github.com/w3c/vc-data-model/issues/877#issuecomment-1225895943.

Manu Sporny: One more item – just so it gets in the record. We also have the concept of challenges and nonce in the variety of the protocols. Lee said – “what about things to mitigate replay attacks?”. Well, we have nonces and challenges and creation dates for the signatures in every security mechanism we’re contemplating.

Kristina Yasuda: You also put that in your comment, right?
… I see Mike is agreeing with you.
… Let’s move onto the next issue.

Kristina Yasuda: substopic: https://github.com/w3c/vc-data-model/issues/860.

Kristina Yasuda: I think you’re asking how we include claims attested to by the user?

Joe Andrieu: That’s right. One of the examples in the VC use cases… Citizenship by Parentage has the citizen / holder making statements about how different VCs relate together.
… It’s his birth certificate with his Mom’s passport, etc. He needs to be able to make a statement that these VCs are related. One option is to create a VC where he does that. It seems it could be appropriate for the holder to make some claims like that.
… I know there’s some background that JSON-LD has an open world model and you can just do whatever you want, but it wouldn’t be interoperable.

Manu Sporny: I totally agree with the use case being a valid one – I’m wondering about the extra complexity.
… One of the options is to define self-attested credentials. Just create another VC in the presentation.
… Option two is to create another way to express this in the VP.

Kristina Yasuda: +1 to using Cs.

Kristina Yasuda: *VCs.

Manu Sporny: I’m worried about adding to the complexity in the VP. I’d like to keep that as simple as we can.
… If we can model it and it makes sense to use a VC then let’s just do that and maybe talk about it in the implementation guide vs. add complexity.

Dave Longley: Yes, going to agree with Manu. We have primitives around interop here, VC can make any claims we want to – seems we can re-use that primitive here and make self-attested claims. When we already have the primitive that does the job, we should continue to use it unless there is a strong reason to do something new.

Michael Jones: Given that’s Joe’s on the call… I tried to read the issue last night but I was confused. It sounded like you wanted a schema for these claims. There wasn’t a clear ask for these particular properties or attributes.
… I think I get it now, but this issue at least needs to be clarified because I couldn’t tell what it was about last night.

Joe Andrieu: I appreciate the feedback.

Kristina Yasuda: Based on the comments we’ve heard using VCs, is that acceptable or do you want to continue the conversation?

Joe Andrieu: It’s a good question. No one has voiced support for the idea – maybe there isn’t support in the community but also maybe it’s just a new idea.
… If we’re going to allow this behavior I think we should standardize it and if we’re not, that’s a shift away from an open world.

Kristina Yasuda: I think there’s interest, I agree with Manu’s comment to give people to think about this and come back to it.
… Do you mind renaming the issue so it’s clear it’s about the mechanism itself?

Joe Andrieu: Yes, I’ll edit it right now.

Kristina Yasuda: One more issue for today…

3.3. Proposal: Anchored Resources and Hashlinks for VCs (issue vc-data-model#831)

See github issue vc-data-model#831.

Kristina Yasuda: … Dmitri would you be able to talk to hash links for VCs?

Dmitri Zagidulin: Sure. In a lot of use cases in the VC world, we need a way to bind not only objects in the VC but also bind other external VCs or other external / outside resource like a PDF.
… Towards that, this issue proposes two new terms that could be used separately or together. One is “anchoredResource” – the general semantic is that in order to fully verify the signature of this VC, you’re going to likely have to fetch other objects and fetch their signature as well.
… The other part of this is the hash link part of this – that’s digestMultibase, it is meant to be paired with the id and whenever you have those two together (and object identified by id with a digestMultibase property).
… Then you can use the multibase encoding to express all of the parameters around the hash, such as hash algorithm and canonicalization algorithm.
… So to summarize, anchoredResource and digestMultibase allows us to bind multiple resources and VCs together.
… It also allows us to do use cases like “endorsement” where you are issuing a VC about another VCs.
… Any questions about the proposal?

Kristina Yasuda: I think people are interested in the use case. I think we want to discuss how we want to address it.

Michael Prorock: I really appreciate this PR / proposal and discussion on it. We run into it a lot on the supply chain side of the world. The thing that threw me a little bit. The first is calling it an anchored resource. The broader use case is to point at some external system. That may or may not be able to have a hashlink with it.
… There might be some UID or something like that – the use cases we have you may look up some organic certification. How we’re handling that today is very similar to what is proposed here. The other two is to attach some additional meta data and structure and vocabularies.
… The third is to use vocabulary terms to define evidence.
… It’s definitely a valid use case and we need to bridge the VC world with legacy / traditional systems. It’s a useful thing to do but it feels constrained to referring to it as anchors or using hash links. I’m not sure we need to standardize that.
… There are a lot of things like lab results and other external docs we want to reference.

Michael Jones: I’m going to bitch about the use of multibase, it’s not a standard in any standard organization. It’s a draft subject to change. That’s one of the things that resulted in the formal objections to the DID specs. I don’t think we should start repeating that mistake.
… There are plenty good IETF hash specs that could be used so that we’re only relying on standards.

Michael Prorock: +1 selfissued - multibase is one of the specifics that concerns me.

Gabe Cohen: -1 - it has broad usage, standards don’t need standards bodies to gain wide usage/adoption.

Manu Sporny: Multibase just went out to dispatch at IETF. The expectation is that it will be a standard soon with air quotes around “soon”. I think focusing on multibase misses the point. This is important, there are multiple industries, supply chain, education, retail that are all using some variation of pattern here.
… It would be great if they were all using the same pattern.
… Multiple industries are solving this in different ways that are incompatible and we’re well positioned to propose something that would work for all of them.

Michael Prorock: +1 manu - this is a pattern recognition item - i will note that not all items have a hash or hash link ability.

Phil Archer: This sounds like something really important to use at GS1. We will look at it in detail and we’re glad to see it.

Michael Prorock: +1 Phil.

Kristina Yasuda: Thank you everyone, that was a great call!.

Kerri Lemoie: Thanks!.

Gabe Cohen: ietf multibase - https://datatracker.ietf.org/doc/html/draft-multiformats-multibase.