Verifiable Credentials Working Group Telco — Minutes

Date: 2023-02-01

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, David Chadwick, Shigeya Suzuki, Phillip Long, Kevin Dean, Chris Abernethy, Kerri Lemoie, Dmitri Zagidulin, Phil ASU, Mahmoud Alkhraishi, Joe Andrieu, Todd Snyder, Manu Sporny, Markus Sabadello, Dave Longley, Gabe Cohen, David Lehn, David Waite, Kristina Yasuda, Ted Thibodeau Jr., Steve McCown, Brian Campbell, Paul Dietrich, Orie Steele, Andres Uribe

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Markus Sabadello, Manu Sporny

Content:

Kristina Yasuda: Agenda today is updates on F2F, then EdDSA crypto suite for Data Integrity, then usual issues.

1. F2F.

Kristina Yasuda: F2F is happening in 2 weeks, location is unchanged.
… Microsoft location in Miami.

Brent Zundel: Attendance sheet: https://docs.google.com/spreadsheets/d/1IguLcaIn8vAo-XDwYXbJTfY2c5SAjA9rgDjo057kKlc/edit#gid=179611341.

Kristina Yasuda: We will have a hybrid setup. If you intend to come in person, please fill in the sheet. We have limited capacity.
… I will send out the registration, just show up and you get the badge. You have to do it every single day..
… For the Wednesday activity, we are planning something like a boat tour.
… I hope all can come and socialize.
… For the actual agenda, can we go through it?.

Brent Zundel: Yes but it may not yet be cleaned up yet.

Kristina Yasuda: Day 1 we’re planning to talk about the media type conversation.
… Then holder binding conversation with Oliver, he has been working on a proposal.
… Then we talk about extensibility mechanisms.
… Evidence, status list, etc..
… Finishing the day with terminology related issues, we’re surprised how many there are. We need to clarify and answer questions..
… (that’s Day 1).
… Second Day: Data Integrity, and VC-JWT.

Brent Zundel: I believe current plan is 1 hour or so after lunch to continue the VC-JWT conversation, possibly issue triaging.
… Then activity after that.

Kristina Yasuda: If we have time, we’d like to talk about vc-jws-2020, status list, use case document, and implementation guidelines document.
… At the end of the day, we want to talk about what deliverables we can achieve by the end of the charter period..
… We hear that some things that can’t be agreed on are put into Implementation Guidelines, we need to clean that up.
… Day 3: Talk about making @context optional.
… After that, session where we share industry news.
… Then we’d like to do issue triaging.
… Coming to the end of day 3, we want a clear understanding of what deliverables are realistic.

Brent Zundel: I’d only add that there are other folks who reached out regarding sponsoring..
… If anyone is willing to sponsor, e.g. the activity we’re planning, reach out to chairs. Also for snacks..

Brent Zundel: socialization email: https://lists.w3.org/Archives/Public/public-vc-wg/2023Jan/0027.html.

2. EdDsa cryptosuite.

Kristina Yasuda: Moving on to EdDsa cryptosuite for Data Integrity.
… We have a process for pulling in new items to the WG.
… Socialize it.. Has been fulfilled, more than 3 independent companies are interested..
… Chairs believe it is in scope for the WG..
… Remaining criteria to include it in the WG is whether there is rough consensus to adopt this as work item..
… In this call, open up the floor to see if there is rough consensus. Chairs will determine if there is such rough consensus..
… If the questions are long, we might decide to move it to a Special Topic Call..

Manu Sporny: To provide some background about the letter that went out. A number of the implementers got together and wrote a letter of support, this includes 19 companies..
… A number of them are W3C members, but also significant number outside of W3C that have implemented this..
… The EdDSA cryptosuite is implemented for TruAge age verifications system, nation-wide, will go in production this year across the US..
… Another interesting use is in the education sector, this was used to demonstrate interop at the Jobs for the Future (JFF) plugfest..
… And a number of people who didn’t have time to get signatures, there are more than that. We see heavy usage for this cryptosuite..

Kristina Yasuda: Thank you for the context manu.

Orie Steele: There has been some back and forth about JsonWebSignature2020 and the canonicalization component of it, which is a major overlap with this work..
… Markus left some good feedback on the list whether there should be canonicalization, or should there be a proof suite without canonicalization.
… Eventually JsonWebSignature2020 might not look so similar to Ed25519Signature2020..
… I think they are different.
… RDF Canonicalization from RCH WG is embedded. I proposed that JsonWebSignature2020 move away from it, due to performance issues with really large documents..
… If you sign really large documents (e.g. in supply chain), it takes a long time to canonicalize it..
… My hope is that JsonWebSIgnature2020 move away from this, so that it becomes a different approach with different performance characteristics..
… Last time we discussed this, there were concerns that they are similar..
… Discussion on the mailing list has been light.
… I don’t think there has been commentary on the Ed25519Signature2020 post on the mailing list. I would like the proof suites to have unique value..

Steve McCown: Question for everybody about the cryptosuite, particularly Orie.
… 1. If we move away from Ed25519, do you have a proposed signature scheme to use instead, e.g. Schnorr?.

Orie Steele: JsonWebSignature2020 in its current format uses IANA registry for algorithms, e.g. for RSA, Ed25519, P-256, etc. curves. JsonWebSignature2020 supports all of those.
… As far as I’m aware there haven’t been registrations for Schnorr algorithms.
… This could be registered with IANA properly. There are suites that support more than Ed25519.

Manu Sporny: Regarding Schnorr, we’ve been talking about doing variations of this in Data Integrity, as Orie mentions there have been experiments.
… There could be another cryptosuite in the future that could be specifically focused on Schnorr signatures, there was input about this by Christopher Allen..

Markus Sabadello: Two things since Orie mentioned my comment on the mailing list regarding JSONWebSignature2020 and canonicalization – my proposal was to use VC-JWS proposal, where VC could be payload of JWS, that seemed a bit cleaner than changing mechanism and canonicalization of JsonWebSignature2020..
… 2nd comment, just want to express support for EdDSA Cryptosuite as work item, as manu said, it’s very valuable, it uses canonicalization mechanism from RCH WG, and important to have these cryptosuites because they sign the canonicalized graph..
… a lot of these discussions are around “do you want to sign the JSON document” or “do you want to sign the underlying RDF dataset?”.
… I support adding this as a work item..

Phil ASU: +1 for supporting EdSA as well..

Kristina Yasuda: There seem to be no objections here on this call..
… I think we do have rough consensus for now..

Brent Zundel: Ideally we’d have a proposal.

Kristina Yasuda: from Orie: Regarding performance issues, https://or13.github.io/decanonicalization/.

Brent Zundel: Any proposed changes to the proposal?.

Proposed resolution: The WG will adopt the EdDSA Cryptosuite (https://w3c-ccg.github.io/di-eddsa-2020/) as a recommendation track editors draft under the shortname vc-di-eddsa.. (Brent Zundel)

Manu Sporny: +1.

Ted Thibodeau Jr.: +1.

Dave Longley: +1.

Markus Sabadello: +1.

Steve McCown: +1.

Joe Andrieu: +1.

Mahmoud Alkhraishi: +1.

Dmitri Zagidulin: +1.

Todd Snyder: +1.

David Lehn: +1.

Phil ASU: +1 for adopting the EdDSA Cryptosuite (https://w3c-ccg.github.io/di-eddsa-2020/) as a recommendation track editors draft under the shortname vc-di-eddsa..

Gabe Cohen: +1.

Kristina Yasuda: brian: +1.

Chris Abernethy: +1.

Resolution #1: The WG will adopt the EdDSA Cryptosuite (https://w3c-ccg.github.io/di-eddsa-2020/) as a recommendation track editors draft under the shortname vc-di-eddsa..

Kristina Yasuda: Orie: For folks who asked about schnorr https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019.

Kevin Dean: +1.

Kristina Yasuda: Editors and chairs and Ivan will work on setting up the repo..

Shigeya Suzuki: +1.

Kristina Yasuda: Let’s go to work item status updates… Any updates from anyone about work items?.

3. Work Item Status Updates.

Kristina Yasuda: We need people working on documents to make sure they are in good shape for publications. Any help would be appreciated..

3.1. Added presentationSchema (pr vc-data-model#987)

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

Manu Sporny: Add presentationSchema. Good discussion going in this PR, it would be good for other people to weigh in. David and I have some level of agreement on what’s meant by this PR..
… I think Orie is right that we need to have a working group discussion so everybody understands what we are doing here..
… Wanted to make sure WG is aware..
… Request to the chairs to schedule some discussion time for this..

3.2. (pr vc-data-model#999)

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

Manu Sporny: PR 999 to remove ZKP section, there is another PR in the works that is more modern, we’re waiting for that to be submitted, then we will look at both PRs side by side to determine which one we want to take..

3.3. Add normative requirements regarding media type and proof (pr vc-data-model#1014)

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

Manu Sporny: PR 1014 about media types. We’re trying to figure out details regarding the media types, how many we’re going to have, etc. This PR is about a very specific media type, and about whether you can include a proof in it, if it can be ignored, etc. Please jump in if you have opinions on media types..

3.4. Typos pointed out in issue 1021 (pr vc-data-model#1022)

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

Manu Sporny: PR 1022 this one was put in by Juan which fixes some editorial issues that were just wrong. Also updated an image. This one looks really good, but would be good to have more reviewers..

3.5. Add language clarifying multiple data schemas (pr vc-data-model#1023)

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

Manu Sporny: New one PR 1023 from yesterday, about credential schemas. This PR says you can have only one credential schema, and then there’s some clarifying language. Please jump in if you have opinions on credential schema..
… This is all about VC data model..

Manu Sporny: https://github.com/w3c/vc-status-list-2021/pulls.

Manu Sporny: Moving on to vc-status-list-2021 PRs.

3.6. Add section about bitstring encoding. (pr vc-status-list-2021#45)

See github pull request vc-status-list-2021#45.

Manu Sporny: PR 45 adds a section about bitstring encoding, how exactly is the bitstring encoded. There’s a PR that clarifies this and adds examples. I don’t think there is a lot of disagreement..

3.7. Ensure that statusListCredential can be dereferenced. (pr vc-status-list-2021#46)

See github pull request vc-status-list-2021#46.

Manu Sporny: PR 46. We have language about the credential, what should you do if it can’t be dereferenced. This PR adds some guidance..
… That’s it regarding PRs.

Kristina Yasuda: To follow up on presentationSchema PR, did you say we need a Special Topic call?.

Manu Sporny: The group needs to discuss this in some manner. Could be done now, or on a Special Topic call?.
… Potentially we could resolve it now in 15 min if the WG understands.

Kristina Yasuda: I think Orie has opinions, might not be quick. Let’s do it on the next WG call..
… Let’s do issues..

4. issue discussion.

Kristina Yasuda: see https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc.

4.1. Representing Multi Issuer Credentials in the VCDM (issue vc-data-model#932)

See github issue vc-data-model#932.

Kristina Yasuda: Issue 932.. Can anyone talk about this specific issue about multi-issue credentials?.

Manu Sporny: At a high level, this is about whether a VC can have multiple issuers..
… It’s a bit deeper than it sounds. On the data model level, of course we could have an array. But then it’s not clear what you do with the proofs..
… Perhaps we want the issuer to be a single field (like it is today), and then have multiple signatures.
… You may have one primary issuers but ‘n’ signatures on the credential..
… And then there’s the argument that we shouldn’t complicate the ecosystem. When you have multiple issuers, ultimately there needs to be an issuing authority..
… E.g. you have multiple schools in a district that test the students, but you only have one authority that issues the credentials..
… There are different aspects on what this is about, and Gabe is leading the discussion..

Dave Longley: or just issue two (or N-many) VCs … need clear use cases and how those could / ought to be solved.

Kristina Yasuda: We discussed mechanisms such as chaining, I think GS1 has something in production with multiple issuers..
… Do we want to define how the multiple issue scenario would work, and if yes which mechanisms do we want to use..

Gabe Cohen: I see signing as a separate concern as the data model. It’s important to clarify the data model first, if there can be multiple signatures..
… A multi signature scheme could be used, or having multiple proofs. I think there is still work to be done in crypto suites..
… I think the requirement is solid, I believe there are situations where single credentials are signed by multiple parties, and the spec text should clarify this..
… We can add language to the spec, even if a crypt suite doesn’t exist yet..

Kristina Yasuda: orie: +1 Gabe.

Dmitri Zagidulin: I agree that multiple issuers is a legitimate use case..
… We have a similar situation in the DID data model, we have the notion of multiple controllers in a DID document.
… We haven’t done much with this mechanism,.
… I recommed that we do not model multiple issuers as multiple signatures.
… Either change the model to allow multiple issuers, or specify the notion of a compound issuer.
… If a student has a diploma from 2 universities, there would be 1 issuer, which is the partnership/combination of the 2 universities..

Kevin Dean: The GS1 example is not one of multiple issuers in this sense.

Dave Longley: +1 to the notion that there are multiple different ways this problem could be solved and needs further exploration.

Kevin Dean: The authority to issue a credential is derived from a prior credential. There is a chain of credentials, but this is not the same as having a credential with multiple issuers..
… My authority to issue a final credential in a chain is derived from previous credentials in a chain..
… Going back to private key cryptography in environments where parties don’t trust each other..

Kristina Yasuda: orie: +1 Kevin, it’s hierarchical.

Kevin Dean: Control of issuing a final credential is put either into completely unrelated party, or it’s under some partial control of one of the parties. This might not be acceptable to others..
… Environment where issuers don’t necessarily trust each other, but they want to issue a credential together..

Steve McCown: +1 Kevin.

Dmitri Zagidulin: treaties and contracts would be best modeled as a COLLECTION of VCs, from individual issuers.

Kevin Dean: For treaties, certain contracts, there may well be requirements for multple issuers in low trust environments..

David Chadwick: +1 kevin.

Orie Steele: I agree with what KevinDeanGS1 said and what decentralgabe said initially.
… We have seen several security approaches to this problem.

Dave Longley: +1 to dmitri … that it may be best to model these things as collections of VCs.

Orie Steele: Going back to what decentralgabe said, the data model is about the intention, and securing it is a separate concern..
… Maybe you’re used to OIDC or access tokens, where you have only 1 issuer and 1 subject..
… The core data model should express the actual information that’s important.
… I feel uneasy how we talk about proofs in relation to the core data model..
… I have a feel we perceive Data Integrity Proofs to be more “imporant” than JWS proofs.
… The data model should be expressed in JSON-LD, and then the security aspect should be modeled using the proofs.
… I’m aware of some of the work dmitriz mention regarding multiple controllers.
… This is not equivalent to a data model that allows expressing multiple issuers.

Kristina Yasuda: what is the value of two issuers URIs if there is only one signature?.

Manu Sporny: The current data model restricts the “issuer” to be a single value. If we just talk about the data model, do we want to loosen that requirement?.

Dave Longley: multiple VCs, each signed by a different issuer, could all make the same claim about a credential subject (such as a treaty) … and merging those together would represent all parties of the treaty signing together, etc. – options to explore..

Dmitri Zagidulin: I think there would be great value if we restrict a VC to a single issuer..
… In the education space, there is a “Comprehensive Learner Record”, which is a kitchen sink approach that contains a lot of information.

Kristina Yasuda: orie: +1 Manu, it would be a change to the core data model first.

Dmitri Zagidulin: This can be a single “outer” credential with “nested” credentials. Each one has a single issuer. The “outer” one is signed by an aggregator..

Andres Uribe: +1 to dimitri.

Kerri Lemoie: CLR spec: https://1edtech.github.io/ComprehensiveLearnerRecord/docs/clr_v2p0.html.

Dmitri Zagidulin: I think we can express these situations while keeping the restriction of having a single “issuer” in the data model.

Kristina Yasuda: I don’t think we’re ready for a PR yet.

Dmitri Zagidulin: +1 dlongley, re having the /treaty/ itself be the subject of VCs.

Kristina Yasuda: I encourage continued conversation about the data model aspect of this..

Dmitri Zagidulin: that’s the approach taken by our recent RWoT paper.

Kristina Yasuda: Thank you everyone, see you next week..

5. Resolutions