Verifiable Credentials Working Group Telco — Minutes

Date: 2023-10-11

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, David Chadwick, Dave Longley, Andres Uribe, Greg Bernstein, David Lehn, Manu Sporny, Kristina Yasuda, Dmitri Zagidulin

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley, Manu Sporny

Content:

Brent Zundel: Our agenda is pretty straightforward.
… We will begin with a CR resolution update.
… We did a resolution to go into CR for Data Integrity, DI + eddsa, DI + ecdsa, VC JSON schema, and we passed a resolution to do that and process has been satisfied but the date needs to change.

Greg Bernstein: +1.

David Chadwick: +1.

Proposed resolution: We set the publishing date for CR for VC Data Integrity, VC DI EDDSA, VC DI EDDSA, and VC JSON Schema to November 7, 2023. (Brent Zundel)

Dave Longley: +1.

Manu Sporny: +1.

Brent Zundel: +1.

Dmitri Zagidulin: +1.

David Lehn: +1.

Greg Bernstein: +1.

David Chadwick: +1.

Resolution #1: We set the publishing date for CR for VC Data Integrity, VC DI EDDSA, VC DI EDDSA, and VC JSON Schema to November 7, 2023.

1. PRs.

Brent Zundel: https://github.com/w3c/vc-data-model/pulls.

Manu Sporny: Just wanted to cover some of the DI PRs. To give an update.

Brent Zundel: That is fine with me.

1.1. Remove normative dependency on Multibase and Multihash. (pr vc-data-integrity#196)

See github pull request vc-data-integrity#196.

Manu Sporny: Mike Jones had requested that we normatively define a number of things in multibase/multihash. The changes have been to define how base encoding works and provide algorithms for base encoding and decoding and specifically provide the alphabets for the bases used.
… Those are the updates and changes and that has gone into PR #196.
… I believe I have addressed every single one of Mike Jones’ requests and questions and AFAICT everything is normatively defined. The hope is to get his review in and get this PR in before Nov 7.

Brent Zundel: Merge it.
… Mike has approved.

1.2. Remove references to Multiformats specifications. (pr vc-di-eddsa#63)

See github pull request vc-di-eddsa#63.

Manu Sporny: That is the basis for the other two PRs.

See github pull request vc-data-integrity#196.

Manu Sporny: PR #63 builds on DI PR #196. My presumption there is if Mike is good with 196, he’s good with the others that refer to it.
… He has +1’d that as well.

1.3. Make all Multicodec / Multibase references non-normative. (pr vc-di-ecdsa#42)

See github pull request vc-di-ecdsa#42.

Manu Sporny: I see he’s approved the last remaining well as well.
… That is great, that unblocks us across the board for all DI and cryptosuite specs.
… That’s that item, we can shift back to VCDM.

Brent Zundel: There are a lot of VCDM PRs.

1.4. Remove “proof” clauses from initial examples (pr vc-data-model#1308)

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

Manu Sporny: Orie raised this to remove the Data Integrity proofs from the initial examples. It has multiple positive reviews, I will probably +1 this as well. There is an open question here, which is, we have examples in the specifications that show how later examples are secured using both DI and, in theory, VC-JOSE-COSE.
… The general question to the group is: Do we want to continue to do that. One of the complaints that we had early on is that we want complete examples.
… Agree that example 1 is probably the wrong place to put that, but do we want examples throughout the spec to show how to secure in at least two different ways.

Brent Zundel: It makes sense to me, to remove the proof property in earlier examples and adding it later to show using it with DI. Particularly because those later examples can be done alongside showing VC-JOSE-COSE securing mechanisms as well.

David Chadwick: I think examples will be very good for future readers.

Dave Longley: +1 to brent.
… +1 for having full examples in the spec eventually.

Manu Sporny: +1 to having at least /some/ examples in the spec of fully verifiable VCs..

Dave Longley: but not having them be the very first one.

Brent Zundel: Anything more to discuss on that PR?
… As long as there remain from DI examples we’re good?

Dmitri Zagidulin: as long as we clearly label it as “Unsigned/unsecured input document” or something similar.

Brent Zundel: I’ll keep going.

Brent Zundel: subtopics: https://github.com/w3c/vc-data-model/pull/1305.

Brent Zundel: This PR removes the CL signature example, which though this makes me sad, it makes sense. I will probably +1 this one myself.
… Urge folks to review as well.

Manu Sporny: Yeah, this PR will probably go in because we don’t have examples of CL signatures today. I will note that Greg Bernstein has raised PRs on the VC-DI-BBS specification to define it using the new format.
… My expectation is that if we do get BBS in decent enough shape we can reinject an unlinkable signature into this part of the specification. That’s my expectation.

Dave Longley: +1 to that expectation.

Brent Zundel: That’s my understanding as well. We’re hoping that folks can step up and serve as the example as the way to do this with ZKP.

Greg Bernstein: That’s looking in pretty good shape.
… I raised some issues using the ECDSA-SD primitives – I was able to reuse the ones from that spec.
… I tried it on VC-DI-BBS and it looked good.
… Along with using JSON pointers to specify mandatory and selective fields.
… I went through the whole exercise of putting BBS together with the SD primitives (core functions) and adding a bit to ensure unlinkability.
… The editors are kind of changing, so there are no reviewers on that PR but I’d like to get people to look at things.

Brent Zundel: Thank you Greg, my hope is that as we move on from the other items as they go into CR we can spend more time on BBS (VC-DI-BBS).

1.5. Editorial cleaning (pr vc-data-model#1304)

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

Brent Zundel: This is some editorial clean up submitted by Orie, a number of approvals already, fixing references.
… I expect this to just be merged relatively quickly, happy to take comments if any.

1.6. Propose better JSON-LD processing text (pr vc-data-model#1302)

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

Brent Zundel: A proposal for better JSON-LD processing text. It has an approval and a bunch of comments. There’s been quite a bit of conversation here.

Manu Sporny: Yeah, so I think around 80% of the text is good. These are good modifications to make. It’s clear that people don’t like the “JSON processing” terminology so we’re trying to say you don’t have to do “full blown JSON-LD processing” and still be ok. The 20% of the text is being debated in the PR. 80% is good clarifications to make, we need to get to consensus on the 20%.
… All kinds of concrete suggestions I made there.

Dave Longley: I feel similarly, there are some good improvements here, good suggestions made by others, would like to see others changes pulled in.
… One of the big things out of this PR is that talking about “JSON Processing” and “JSON-LD Processing” is problematic, because those terms mean different things to different people. If we can avoid using that terminology, and just talk about specifics on consuming data, that would be best.
… Some text suggested in this PR would help us get there.

Brent Zundel: Not seeing anyone else on the queue, next steps would be Orie jumping in and accepting suggested changes or continuing the conversation there.
… This PR looks to be in a decent spot.

1.7. Remove JSON Processing section (pr vc-data-model#1298)

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

Brent Zundel: This PR removes the “JSON processing” section. There’s been some conversation. There has been request for changes.
… Looking for conversation here to see it move forward.

Dave Longley: This PR is an alternative to the one we discussed, I don’t expect this PR to go in, if we get good consensus text on the other PR we just discussed. The other PR would be better for understanding what people would need to do.

Brent Zundel: If the other PR goes in, this one gets closed?

Dave Longley: That’s my expectation.

1.8. First pass at updating validation language (pr vc-data-model#1297)

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

Brent Zundel: Joe has a response to an open issue.
… This updates the language in the spec around validation.
… There has been conversation, suggested changes that aren’t in yet.
… There’s at least one person that has approved it, we perhaps need more review.

Dave Longley: I haven’t had enough time to look at this one, initial scan seems to add normative requirements around statements that are not testable… Verifiers must validate claims, that’s usually done via business rules… validate using included business rules… we’ll need to adjust that language in some way… not something an implementation can do… you might need to use your own business rules.
… Appreciate the effort to get clarity on verification vs. validation.

Manu Sporny: The only concerning bits of the PR are around normative statements around validation. I know Jeffrey Yaskin wanted us to specify verification algorithms, but validation is a bridge too far.
… There are multiple statements in this PR that say things like “verifiers MUST validate claims in VCs” which, again, is not testable. We don’t want to get into validation rules.

Brent Zundel: I agree with that. I wanted to ask if the normative text here might be … one of the suggestions made was that we more clearly define conformance rules. We could say “a conformant consumer of a VC… ought to do”, whether and how that language would be normative around that is a another discussion.
… Perhaps putting this into conformant producers and consumers of the document is a step we could take. “Here’s this data model and if you want to do something with it, here are some rules around that”. It might be helpful if we went there.

Manu Sporny: One approach we could take there is the approach we took in the DID spec for DID method spec authors. We had normative statements around what DID specs must do – I think Jeffrey Yaskin’s review also covered that there are conformance classes in the spec that we don’t define like conforming issuer/verifier.

Brent Zundel: +1 that’s what I was getting at.

Manu Sporny: I think that’s what you were getting at Brent, so we could have sections in the spec about what a conforming verifier must or should do and hand wave over that and say – while those statements are normative, we’re just saying what’s expected from the conformance class, now how to do it but that one must do it.
… That might allow us to write normative statements and that we don’t have entries for that in the test suite because it’s general guidance.

Dave Longley: it’s “business rules”, not something a generic implementation would do.

Manu Sporny: Saying it out loud sounds problematic … that’s somewhere to try and go though.

Brent Zundel: For this PR advice would be to get rid of normative language, recognizing that moving forward with conformance on issuer/verifier roles we might need some “more normative” language and that might not be testable, but separate PR for that.

Manu Sporny: +1 to approach brentz suggested.

1.9. Add relatedResource and digestSRI to the vocabulary (pr vc-data-model#1296)

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

Brent Zundel: One approval, a bit of explanation from Ivan.
… This feels like a PR that just should be merged … to me, but happy to hear otherwise.
… I’m not hearing otherwise, encourage folks to jump on, review and approve to get it in.

Manu Sporny: +1 to this PR.

1.10. Update to Terms of Use description (pr vc-data-model#1295)

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

Brent Zundel: Raised by David Chadwick to add examples of terms of use. A number of suggested changes that folks have made, not clear if those changes have been addressed.
… A number of reviewers requested changes. Let’s talk about this PR a bit.

David Chadwick: So I have made all the changes that people have requested and I have re-requested reviews.
… There is one issue that I couldn’t resolve.
… Previously I had a reference that I changed to an informative reference, I couldn’t figure out where the informative references are held … I can actually add it properly.
… If someone tells me what to do.

Manu Sporny: There’s something at the top of the document or in a file called biblio.js – look there.

David Chadwick: Ah, I didn’t look there.
… It’s just JavaScript?

Manu Sporny: Let me check.
… It’s in a file called “common.js”.
… If you add your link there, it will show up in the spec.

David Chadwick: Ok, got it.
… Thanks, I can sort it now.
… I’ll push that in another PR today or tomorrow.

Manu Sporny: I think Kristina is concerned that this PR doesn’t address – the issue associated with this PR, there are two parts. One is to use a more accurate example, and that is done. We also wanted to demonstrate that this is broadly used and deployed and said so in the comments but Kristina’s concern was that we’re still not very clear when you use terms of use or how to use it.
… I’m wondering if we can deal with that in another PR or if you can address that here, David.

David Chadwick: So I have altered the text. The original text was generic, and just before the CR or after … we put more text in around mandatory requirements. That then, throughout the whole of the text … the text before that was put in was very generic. What I’d done is I’ve now created a couple of examples in generic examples to say “it may be either of the following”, it doesn’t pin down that terms of use must have these three prohibitions or whatever.

David Chadwick: It wasn’t an example before and now it’s an example.
… It still has that in the second example now. The whole shift in version 1 and version 1.1 was skewed … from the original terms of use to now go back to the original text to become more generic, so the prohibition stuff is now in an examples. We have an example where the issuer has to conform to terms of use and another example for a holder with prohibitions.
… If Kristina can come back and say what else to change if more is needed that would be good.

Brent Zundel: I see last week Kristina put herself to re-review.
… Next step is review from Kristina and other folks, particularly those that have requested changes to see if their requests have been addressed or not.
… Kristina, Orie, Manu are some names here.
… Any other comments?
… We will skip 1294 because if 1295 gets merged then 1294 will be closed.

1.11. Privacy considerations around issuer location (pr vc-data-model#1286)

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

Brent Zundel: Privacy considerations around issuer location. Raised by Gabe to address an issue – specifically calls out for review from TallTed.
… I think we got that.
… Any comments folks want to make – seems to be a straightforward PR to review and merge.

1.12. Add links to static copies of vocabulary files and hashes (pr vc-data-model#1279)

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

Brent Zundel: Raised by Manu.

Manu Sporny: I don’t know what to do with this PR just yet.
… It felt like Kristina, Orie, and Ivan were asking for some irreconcilable things, I imagine we need the three of them on the call to figure out what to do here. I think Kristina and Ivan might be agreeing to remove the schema.org stuff – I can’t tell if Orie would be ok.
… I think that’s where we are … some concrete text from Orie could resolve this or time on a call to discuss.

Brent Zundel: Thank you, Manu.
… We’re at the point of trying to get to CR, with a PR like this, it’s been raised, people have come back and say “I don’t like it, I want changes” … we’re running out of time for back and forth. We don’t have time for requests for changes, review of that, responses to that, responses to those responses, etc.
… This group will need to decide soon on a shifting of our work mode to move through these things. If a PR doesn’t gain consensus quickly we will have to look at just closing it if we don’t have the capacity to address it.
… Having soapboxed for a moment there, let’s jump into 1276.

1.13. Provide guidance to use compact terms/types instead of full URLs (pr vc-data-model#1276)

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

Brent Zundel: Guidance for the use of compact terms and types rather than full URLs. I know this is related to the light processing PRs.

Manu Sporny: There’s an issue raised to provide clear guidance on using compact terms vs. full URLs. I think Orie is saying that this PR doesn’t address this issue and it might be better address in the value of JSON-LD PR. I don’t know what is needed to make it so that Orie is ok with it. It is a PR that would be closed because we couldn’t get to consensus.

Brent Zundel: Thank you, Manu. We’re at time for the meeting. Appreciate folks joining, kinda crazy with people at IIW, etc.
… Thank you for scribing, Dave, thanks for all the work people have done, see you later!

2. Resolutions