Verifiable Credentials Working Group F2F at TPAC, 1st day — Minutes

Date: 2024-09-26

See also the Agenda and the IRC Log

Attendees

Present: Kevin Dean, Ivan Herman, Gabe Cohen, Manu Sporny, Benjamin Young, Greg Bernstein, Wesley Smith, Brent Zundel, David Ezell, Shigeya Suzuki, Jennie Meier, Denken Chen, Michael Jones, Will Abramson, Dave Longley, jets, David Chadwick, Paul Dietrich, David Lehn, Dmitri Zagidulin, Nicholas Steele, Geunhyung Kim, Kurosaka, Juan Caballero, Brian McManus

Regrets: Ted Thibodeau Jr.

Guests: mandyv, laurens, Jay Kishigami, Wonsuk Lee, EricS, Heather Flanagan, osamu, Shigeya Suzuki, Bert Bos, Tatsuya

Chair: Brent Zundel

Scribe(s): Wesley Smith, wes-smith4, Kevin Dean, Manu Sporny

Content:

Kevin Dean: https://docs.google.com/spreadsheets/d/18As8BMku1s536XxrJNvKus-08w-bGc1bRqvqzrGPpE0/edit?gid=179611341#gid=179611341.

Jennie Meier: https://docs.google.com/presentation/d/1rjt4fgajEqqQzdF72JUeh6_h4gICQanExOfcoW4l0GM/edit#slide=id.p.

Brent Zundel: going to do introductions, lots of folks who might not have been to a meeting before.
… no real format to the intros, who you are, who the member org you represent is, fun fact.
… Brent Zundel, mesur.io, we sponsored the gala last night, been involved with VCWG for very long time.
… happy to be here, if my feet could taste my socks would have to taste like beef jerky.

Gabe Cohen: Gabe Cohen, block, want to let you know that snails have over 20k teeth.

Denken Chen: working with Taiwan’s government with VCs.

max: Max, involved with VCs for many years, first time at one of these meetings.

Enrique: Enrique Xavier, here as an observer.

Wonsuk Lee: Wonsuk Lee, member of automotive working group, involved with DID working group, VCWG, South Korea already develops and uses DIDs/VCs for mobile driver’s license.

Laurens: chair of linked web storage working group, here as on observer.

morimori8: primary area at w3c is authentication, identity proving naturally becoming important, I learned about this WG last year, excited to see the progress.

Jay Kishigami: Jay Kishigami, W3C team. Thank you for the people who joined “Web on the Moon” yesterday Breakout session. Interested in VC because of high expectations for VCs.

Jennie Meier: Jennie from digital contract design.

Kevin Dean: kevindean from legendary requirements.

mandyv: Mandy Venables, digital bazaar.

Benjamin Young: Benjamin young, digital bazaar, I have an extra vertebrae.

Ivan Herman: Ivan Herman, w3c, staff contact for this working group.

Michael Jones: Mike Jones.

David Ezell: David Ezell with Conexxus, standards org for retail space, we use VCs heavily, successful program going bc convenience stores have bad reputation for keeping up with age verification etc, and bad rep for handling private information, VCs are a game changer for us.

Will Abramson: will abramson, digital contract design.

Heather Flanagan: HeatherF: Heather Flanagan, Spherical Cow Consulting, Observer and chair of the FedID WG (and the IETF SPICE WG).

Geunhyung Kim: Geun-Hyung has joined #vcwg.

Greg Bernstein: Greg Bernstein, independent, invited expert, I generate test vectors in the crypto suites, if you are implementing and run into problems please contact me, I have open source code to help, also working on crypto suite drafts and privacy preserving signatures at the IETF.
… putting in things like anonymous holder binding and pseudonyms.
… help get privacy going alongside secure cryptography.

sven: Steven Venema, joined MSFT recently, new to the space, happy to learn.

Wesley Smith: ???: cryptographer at Meta, just observing.

Manu Sporny: Manu, Digital Bazaar, one of the editors here.

Manu Sporny: wes-smith: Wes Smith, Digital Bazaar, happy to be here.

Wesley Smith: ???: from Keio university with Shigeya.

Greg Bernstein: Extra info for cryptosuite interested folks: https://www.grotto-networking.com/VerifiableCredentials.html, has links to presentations, specs, and open source code for test vectors and more.

Wesley Smith: ???: Kay from Singapore gvt, using VCs in work on digitalizing international trade documents, if you have attended breakout session yesterday we talked about VCs and NFTs to handle trade docs.

cc: Calvin from Gvt technology agency of Singapore, working with Kay and other colleagues on technology side, we have open attestation framework, looking to try to promote that to be published.

SinYong: also with infocom media development at Singapore, working on project to digitize trade documents.

Isaac: also from IMDA Singapore, nice to meet you.

shiyu: Shi Yu from GovTech Singapore.

Bert: I’m Bert Bos, W3C team, here as an observer.

Wesley Smith: wes-smith has joined #vcwg.

jets: I’m Brian McManus from Ignite Retail Technology. I go by ‘jets’ on IRC. We joined W3C in January and are new to this working group. When I found out IRC was used for scribing and managing meetings, I told a colleague, ‘I’m with my people!’ David Ezell from Conexxus encouraged us, as retailers, to get involved. We’re particularly interested in exploring Verifiable Credentials for loyalty programs in convenience stores.

Kyle Den Hartog: Kyle: Kyle from GovTech Singapore, Software Engineer on the OpenAttestation framework.

Brian McManus: Brian, we joined W3c in Jan, new to this working group, using VCs for loyalty programs in retail space.

rigo: From w3c team, interested in the semantics side of VCs.

Wesley Smith: ???: from Ericsson research.

osamu: osamu: Osamu Nakamura from KEIO Univ.

Kay: Hello, Kay Ren Yuh, Infocomm Media Development Authority, working in a project that entails using VCs to digitalise cross-border trade documents.

David Lehn: David from Digital Bazaar.

elundberg: Emil Lindberg from Yubico, here as an observer, active in European identity work.

paul gs1: Paul Dietrich from GS1, standards org that does identity for supply chain.

Dave Longley: Dave Longley, digital bazaar, fun fact, the congressman who wrote the legislation permitting commerce on the internet represented DB’s hometown.

1. Charter renewal.

Ivan Herman: not going to walk through VCWG charter, voting ended a week ago, no problems, enough yes votes, there are some comments and abstentions.
… one abstention also included comments, we could choose to ignore them but would prefer not to.
… I prefer with a few non-obvious changes to have feedback from the group.

1.1. Checking the liaison statements (pr vc-wg-charter#125)

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

Ivan Herman: one PR which I already made that includes the changes on liaisons, the comment came because we did not change a particular statement from the old charter, we did not check to make sure it was still valid.
… two notable things, one was that the RCH WG has finished its work and is in maintenance mode, we don’t expect to do anything with them, no need to list as liaison, the PR removes that one.
… also there was an incorrect URL.
… for the other liaison statement, I would like feedback from the group, liaisons for other WGs are not controversial, liaisons outside the WG I personally cannot judge if they are valid or not.
… the external organizations here, tell me if there is one or two you would prefer to remove.
… or tell me it is good as is and to move on.
… Brent and I looked at it, the only thing that at that point we we unsure of was whether hyperledger Aries was still active.
… unsure if that liaison is still worth having.

Manu Sporny: AFAIK the Canadian gvt, which uses VCs, is heavily invested in hyperledger Aries, the acapy implementation for VCs is associated (maybe) with aries.

Ivan Herman: leave as is, then.
… are there any other switches the group would like.
… once.
… twice.
… please put up the other pull request.

1.2. Removed the reference to an HTTP spec from the “Other deliverables” list (pr vc-wg-charter#126)

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

Ivan Herman: this one refers specifically to the reference to a CCG document on HTTP API for digital credentials, it was said that this document is normative looking, either it should be listed as a deliverable/rec track document or be removed.
… we have discussed this separately, it turned out the CCG intends to potentially submit that document to either this WG or a later incarnation as a rec track document, which for me means that it must be removed from the charter as is right away.
… in the last change of W3C process, it’s no longer a real thing to create a WG note which then is turned into a rec track document later, for some reason that is now frowned upon.
… counterproductive to have this doc as a deliverable/WG note.
… should immediately remove this.
… also would satisfy commenter.
… any pros/cons?

Manu Sporny: +1 to remove it, the intention is to take it rec track, cannot publish as note.

Ivan Herman: I will merge this PR.

1.3. Further steps.

Ivan Herman: I will ask management to start the new charter on 1 Nov.
… if we all agree that’s all I have to ask.

Brent Zundel: from our perspective, the IPR has not changed in new charter, no members need to rejoin?

Ivan Herman: correct.
… I wish all items today were as easy as this one.

Manu Sporny: great news, in the current charter/new charter, we will continue the work we started, finish it, then maintenance mode.
… in there was continuing to finalize things like renderMethod, confidenceMethod?

Ivan Herman: correct.
… I made the PR to add those, DB rep approved.

Brent Zundel: Done with intro section, have our first major topic through the break.

2. VC Data Model.

Manu Sporny: https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240918/.

wes-smith4: wes-smith4 has joined #vcwg.

Manu Sporny: this is our core spec, we are attempting to publish version 2.0 ASAP, this defines a core data model for VCs.
… provides short intro, high level overview, basic concepts for credentials.
… what the credential is about (credentialSubject), validity period, associate info with the credential like status info, allows you to associate data schemas with the credential to make sure the credential is well formed.
… then we get into securing mechanisms, how do you cryptographically protect the credential, number of securing mechanisms we will discuss, this is the thing that makes the credential verifiable.
… then talk about verifiable presentations.
… advanced concepts section talks about trust model, ensuring integrity of linked resources, ZKPs, representing time, terms of use, how other ecosystems can be compatible with VC ecosystem, complex topics like graph based data model, securing mechanism specifications.
… syntaxes section, used to talk about multiple syntaxes, now focus on JSON-LD.
… talk about media types, algorithms for verification.
… privacy/security considerations sections in the document as well.
… also talk non-normatively about verification vs validation.
… talk about contexts and how to secure them and use them safely.
… finally we talk about media types.
… it’s a large document, we have been processing issues, went into first CR months ago, have been processing mostly editorial but some normative issues, we will need second CR, will talk about that today.
… let’s look at the issue tracker.
… we have 6 issues left on the spec, 3 of them have been marked for future (deferred).
… two of the remaining are editorial, one has PR ready to merge.
… asserting we don’t need to discuss these.

Manu Sporny: See Test suite.

Manu Sporny: the other thing is our test suite, we have the results of our test suite.
… if we look at our test suite, our slides say we have 5 implementations, it is now 6, the Implementations are looking good, there are a couple where weird conformance statements might need their tests removed.
… if we go to presentations section, only 1 implementation, I know that there are multiple implementations, have been waiting on media type decision for vc-jose-cose specs to finalize those.
… we have more than enough implementations, there are features we expect implementers to implement once we make a decision tomorrow.
… the spec is in good shape, we circulated a static version of it a while ago, just using CR draft, we have 6 implementations, for the issues that don’t have enough implementations right now, going to mark them “at risk” before CR2.
… expect those at risk markers to be removed.
… the next thing we could do is pass a proposal to go into CR2 with the VC core data model, the current proposal is a 30 day review period on CR2 with clearly marking features w/o enough implementations as at risk.
… for open issues, we have PRs and will merge those before 2nd CR.

Brent Zundel: which of these PRs could we merge right now?

Manu Sporny: remove problem detail integer error codes.
… all of them except the top one.
… a little concerned about merge conflicts.

Ivan Herman: let’s not do that there [laughs].

Manu Sporny: presumption is we will merge all of these before CR2.
… one of them we might not, abstract one, but that is editorial.
… revised statement: some of the editorial stuff might not be merged before CR2 because it can be handled in CR2.

Ivan Herman: practical question, do we intended to synchronize that publication with other CR2s.

Manu Sporny: nods.

Brent Zundel: next PR is one that absolutely must be merged before we go to CR2, it has been open for weeks, my suggestion is that we merge it.

Manu Sporny: has plenty of approvals, 2 weeks of review, no objections, unless there are objections here we can merge.

Brent Zundel: please do.

Manu Sporny: merged.

Brent Zundel: I tweaked the language in Manu’s proposal, anyone that would like to suggest changes to this language?

Greg Bernstein: Link to slides: https://docs.google.com/presentation/d/1rjt4fgajEqqQzdF72JUeh6_h4gICQanExOfcoW4l0GM/edit#slide=id.g477278097e_0_13.

Michael Jones: I’d like us to discuss that there is normative dependencies on this spec to chain of other specs, DI, Jose-cose, controller document.
… don’t anticipate us making changes to this spec bc of resolutions to the others, but might occur.
… might be prudent to send them all down the pipeline at the same time.

Brent Zundel: that’s the plan.

Ivan Herman: no, what he says is the resolutions.

Michael Jones: the proposal makes it sound like we will publish second CR before we are ready for second CR for specs it has dependencies on, not ok with this.

Manu Sporny: my concern is controller document, a number of things to discuss there tomorrow, I thought the agreement was it would be fine to publish controller document, DI, as second CR, because we don’t expect any changes in controller document.
… publication of VCDM 2.0, DI, in a chunk, if we can, publish VC Jose-cose, but decouple so that if we had a problem with those documents it wouldn’t hold up other ones.
… goal was to publish things ready now (DI, VCDM, EC/EDDSA crypto suites), attempt to publish other documents.

Ivan Herman: things only have to sync up at recommendation phase.

Michael Jones: I would prefer that we wait to do this until near the end of the day tomorrow.
… there are substantive issues for vc-jose-cose that could require normative changes to the data model.
… we should make decisions at the end of tomorrow and discuss specs first.

Manu Sporny: what would change? I don’t know what would change.

Michael Jones: the media type could change.
… we need to be creative about how to resolve that across all specs.
… in a consistent way.
… would like us to resolve all issues we can before we push the button.

Manu Sporny: for the record, Digital Bazaar would not prefer to do that, we have a lot to do tomorrow, will delay everything if we cannot pass these resolutions, no material impact on the specification.
… if we change something fairly drastic, we can claw back the resolutions, any large change at this point would raise objections.
… such that the change would not be made.

Gabe Cohen: will suggest what Manu said, should go forward with this proposal for sake of agility, if it needs to change we can run another proposal.

Brent Zundel: our operating mode is such that when we make a resolution, there is a 7 day countdown window where anyone can object, that person can have voted for it in the first place. in my opinion as chair, passing this resolution now is in line with selfissued’s suggestion.

Michael Jones: OK.

Brent Zundel: once again asking, any proposed adjustments to this text that you see as necessary before we run it as a proposal.
… not seeing anyone on the queue.

Gabe Cohen: https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240926/.

Ivan Herman: the URL there is probably no longer true, you have made a merge of the docs, the latest version we are trying to publish does not have that date.

Manu Sporny: can use new CRD.

Ivan Herman: remove the URL and put something there.

Proposed resolution: Publish the latest VC Data Model v2.0 as a 2nd Candidate Recommendation with a 30 day review period after PRs for AT RISK features and all current open issues have been addressed. (Brent Zundel)

Brent Zundel: +1.

Gabe Cohen: +1.

Ivan Herman: +1.

Dmitri Zagidulin: +1.

Dave Longley: +1.

Manu Sporny: +1.

Shigeya Suzuki: +1.

wes-smith4: +1.

Benjamin Young: +1.

Will Abramson: +1.

Jay Kishigami: +1.

David Chadwick: +1.

Jennie Meier: +1.

Paul Dietrich: +1.

Brent Zundel: seeing and hearing no objections.

Resolution #1: Publish the latest VC Data Model v2.0 as a 2nd Candidate Recommendation with a 30 day review period after PRs for AT RISK features and all current open issues have been addressed.

Brent Zundel: that takes us to the end of our first session.
… early for our break, time is wrong anyway.
… on slides.
… break starts at 10:08, lasts until 11.
… Next session is all about data integrity.

Wesley Smith: wes-smith has joined #vcwg.

3. Data Integrity.

Manu Sporny: https://www.w3.org/TR/2024/CRD-vc-data-integrity-20240919/.

Manu Sporny: Link to current candidate recommendation.
… VC Data Integrity is one of the securing mechanisms in the VCDM. In order for a credential to be verifiable, it must be secured.
… The data integrity spec establishes a baseline way to secure something. To make it concrete, you have to apply a cryptographic suite, specifying algorithm and key type and the process of securing and verifying the payload.
… Document has boilerplate stuff followed by a data model.
… Talk about things like sets of proofs (parallel signatures), proof chains (dependent proofs, e.g., individual followed by notary), proof graphs (proof separate from the data that it is securing), proof purposes (e.g., authentication, assertion of some statement), resource integrity, JSON-LD context and vocabulary, relationship to linked data and VCs, base cryptographic suite type.
… There are algorithms as well for adding a proof and verifying a proof, how to do context validation (added due to issues raised), defining processing errors and types for developers.
… Health-sized security and privacy considerations sections.
… Detailed explanation of how proofs work in an appendix.

Manu Sporny: https://www.w3.org/TR/2024/CRD-vc-di-ecdsa-20240916/.

Manu Sporny: Paired with this document, using ECDSA as an example, we have cryptosuite specifications covering things like the data model specific to the algorithm, how the proof is represented, and the algorithms for adding a proof (RDF or JSON canonicalization, selective disclosure, derivation, etc.).
… ECDSA as an example provides three cryptosuites.
… RDF, JSON-LD, JSON.
… There are test suites. The way that we test these documents is to test the data integrity specification in each cryptosuite.
… You’ll note that session title says “Data Integrity” and then which cryptosuite is being tested. We rerun the tests for every single cryptosuite.
… We have demonstrated multiple interoperable implementations for ECDSA.
… We have at least one that doesn’t have many implementations. When that happens, we mark it as at risk when we go to candidate recommendation.
… It is interesting to see when one organization generates a signature and another verifies it, we find gaps in implementations.
… That’s important because interoperability is important.
… We test VC 1.1 and 2.0 in the crypto suites.
… Brent just said that he didn’t see anything that didn’t have at least two implementations.

Benjamin Young: We went through everything and there are at least two for each.

Greg Bernstein: I want to point out that appendices on test vectors are very worked-through examples for anyone trying to do implementations. They show a developer all the steps and we keep those very up-to-date with the text. When we add any normative change, we update the test vectors.
… My implementation may be lagging, but they are there to help folks keep up. Every cryptosuite has those.

Ivan Herman: You treated that table on interoperability sort of off-hand saying that it’s not required but we did it. I say that it is required even though not in the text. If we didn’t have it, we would get feedback saying that we didn’t test interoperability. I think it’s important and hope that we have the same table in all cryptosuites.

Manu Sporny: We haven’t had to do that in other working groups.

Greg Bernstein: Note all cryptosuites have “test vectors” which are fully worked through examples of securing a VC. The code for producing these vectors is open source. See links on my VC page: https://www.grotto-networking.com/VerifiableCredentials.html..

Ivan Herman: We had comments that we have to prove the interoperability of these things.

Benjamin Young: Required or not, we have it.
… Go team!

Manu Sporny: Data Integrity has three issues, two editorial. ECDSA has three issues, two editorial. EdDSA has zero issues.
… The test suite for Data Integrity has eight implementations, ECDSA has six, EdDSA has eight. If there are any features in the test suites that don’t have at least two independent implementations we would mark them as at-risk before going to CR-2.
… Issue 76.

3.1. DRY principle for multikeys? (issue vc-di-ecdsa#76)

See github issue vc-di-ecdsa#76.

Ivan Herman: For whatever reason, we have now the cryptosuite and the DI spec and the controller document. Not interested in how it came into being. The controller document has been put forward as abstracting a number of features, terms, and data types that are shared by different specifications, including some not in this group. I think that’s a good thing. At least in my mind, a controller document should ge usable in applications that have nothing to do with VCs or DIDs.
… The multikey format (abstract) has been put into the controller document. The multikey specification format is useful if its defined for each algorithm (ECDSA etc.).
… Currently, this definition is duplicated. That’s bad. We don’t repeat ourselves, otherwise we get into trouble. It is my fairly strong position that it must be in the controller document and only there. Let’s say that I want to make an application that signs an email. That has nothing to do with credentials or cryptosuites. Multikey gives me a compact representation form.
… Using ECDSA, I may have to go to the data integrity specification to get full details.
… The right place is to have it in the controller document only.

Manu Sporny: The slide has three options. There are a couple of challenges with putting all of the key definitions in the controller document. Multikey and multibase have jumped specifications multiple times; they should be their own specifications so that people can refer to them in their own way. We’re not doing that.
… We tried to publish at IETF and were blocked, so we put them back here.
… The thing I’m most concerned about is that cryptosuites need to specify which key types work with them.
… Let’s say we create a new cryptosuite that uses a new key type. If so, we would have to reopen the controller document to define the key type. I think that the right approach is for cryptosuites to define their own key types and for their key types to be in a registry somewhere.
… We have comments that people didn’t want to refer to other documents for the key specification.
… Putting it in the controller document means that you would have to reopen the controller document for each new key format.
… Putting it in the cryptosuite document makes it easier to add new key types. The way that we have it now is unfortunate but is a compromise that allows us to get through without objections.

Ivan Herman: I won’t lie in the road to get in the way. I see a fourth possible approach, possibly sub-optimal, that we move everything into the controller document, publish everything because we’re under time pressure, and then in maintenance we work out a way for people to add new keys on a website or similar.
… We don’t have the time to do it fully and cleanly, but we can open the way to do it later.

Manu Sporny: We have the VC extensions. We could add another table there where we could add new registries there that would allow you to add stuff. My concern is still the same. Cryptosuite specifications need to be able to define the key types.

Dave Longley: +1 to using extensions and language that says cryptosuite spec authors can define new/reference new key types.

Manu Sporny: As long as we have language that allows cryptosuite authors to add key types, we’re probably fine.

Ivan Herman: I have the impression that this is something that should be there anyway. The statement that you made is regardless of whether the cryptosuite has them or not. That guidance should be there, regardless of the outcome of this issue. Putting it into VC extension for now works for me. We can clean up in maintenance.

Manu Sporny: I’m worried about the changes that this might make to the specification. Can we take those definitions out of the specs and put them in the registry?

Ivan Herman: No.

Manu Sporny: I’m worried that there’s some language in the cryptosuite specification that may trigger some kind of issue if we do this.

Ivan Herman: After cursory look, for me, there is one paragraph that could be replaced with “look at table in controller document”.
… Definition for multikey for ECDSA is a single paragraph.

Manu Sporny: What if we say that the controller document establishes a registry for multikey and multibase and then we point to the registry.

Ivan Herman: The registry can define multikey with no additional references required.

Michael Jones: I disagree. Registries are never the authoritative definition; they refer to authoritative definitions in specifications.

Brent Zundel: What registry are y’all taking about? We ain’t got none of those.
… This group decided very firmly to not have anything to do with registries, which, on the record, I disagree with.

Manu Sporny: The changes would be that the controller document would point to the VC extensions list, if you’re interested in any of the values, go to that table.
… It would be the same content but shifted over to VC extensions.

Ivan Herman: That document can’t have the authoritative definition of a key because it’s a note.

Dave Longley: +1 to using VC extensions and have each entry there list the spec where the key definition is.

Ivan Herman: We open up a table which can point back to the controller document. If at some time later someone comes up to an authoritative definition for multikey, we can point to that definition.
… For the WG purpose today, we have a table for all multikeys that we define in the controller document and we create an index for developers to find them easily.

Manu Sporny: What that means is that we cannot add anything new if we do not have a working group.
… Other working groups can, but we would not be in a position to say that what they did is authoritative.

Gabe Cohen: We need an approach that allows us to register new security mechanisms after this group has left.

Manu Sporny: The other thing to consider is that the thing that is normative is the specification, not the registry.
… That means that that list doesn’t need to be normative. We can have a statement in a normative document pointing to a note.
… In the controller document, we can have a section that says that if you’re interested in key types, go to this list of extensions, and it will list all the key types.

Ivan Herman: You are doing a sneaky way of doing what is there. My idea is almost what you say but not exactly. In your scheme, you keep the ECDSA version in the ECDSA cryptosuite. My variant is to have what we define in the working group in the controller document.

Dave Longley: +1 to Ivan’s proposal.

Ivan Herman: We can then point to an index to look up additional definitions and move what we have defined into the controller spec.

Manu Sporny: I would be fine with that as a compromise.

Michael Jones: A lot was said in the last ten minutes about what changes have been proposed.

Manu Sporny: We are going to put the key definitions for multikey in the controller document; they are already there and will remain. We are going to modify the controller document to point to a list of other key extensions and remove the definitions from the cryptosuites.

Denken Chen: +1 to the current resolution here. It helps from the developer’s side to avoid confusion.

3.2. Multiple significant security vulnerabilities in the design of data integrity (issue vc-data-integrity#272)

See github issue vc-data-integrity#272.

Manu Sporny: Currently there are 145 comments regarding security vulnerabilities.
… The matter of concern is about security the context: using content integrity on the context.

Wesley Smith: wes-smith has joined #vcwg.

Manu Sporny: We have made adjustments to the core specification to @vocab, no longer using it by default.
… We have enhanced the content of the validation process in the data model and the data integrity specifications.
… We have enhanced the document process and have committed to adding the attack initially described to the test suites.
… There has been a partial implementation/discussion around content integrity protection over the context.
… There have been a number of discussions where if the verifier knows what context they’re process, that there is no attack.
… One of the proposals on the table is that if an issuer secures the context, a verifier must verify the context. That would enable issuers that are concerned about this to force verifiers to do what they want.
… Securing the context means adding a cryptographic hash of the context to the context URL in the VC.

Brent Zundel: You said something during the break, Manu, that the changes that have already been made mean that when an issuer proves a context, the verifier needs to already be aware of the context prior to receiving the content.

Kevin Dean: An immediate concern with verifier receiving content… there may be contexts that are extensions of those that are already known. I could receive something that builds on top of existing context, relies on underlying context when I’m processing.
… Seems highly restrictive for verifier to know what they have to receive.

Dave Longley: A context URL is either well-known or opaque. A well-known URL will appear as a constant in source code. You’ve written your application against the terms defined in the context. Otherwise, you have an opaque URL. Your application cannot process against that as it’s not known to the application.
… If your application wants to process opaque contexts, the document must be transformed to one that the application understands.
… It’s OK to read the terms you understand and ignore the ones you don’t.

Manu Sporny: An attack has not been demonstrated. There’s no code that demonstrates an attack that the specification defines for context management.

Dmitri Zagidulin: I don’t take issue with there being no attack demonstrated. It would not go amiss if we required cryptographic verification by the verifier of the terms in a related context. We have this resource, we have cryptographic protection, so why not make it required by the verifier even if there is no demonstrated attack?

Dave Longley: If an opaque URL shows up, you must transform that document to something you can understand before you can consume it. On top of this, the cryptosuites protect the document, so verification must take place first. Only after that does the context define how the document must be processed.

Denken Chen: +1 to dmitriz.

Dmitri Zagidulin: Adding that requirement to verifiers has additional benefits. It prevents developer confusion if the context changed. I agree that hash checking isn’t required but adds value to the verification.

Dave Longley: dmitriz, what you’re talking about to me, is “differently identified contexts, which happen to be content identified” which, to me, is a separate consideration entirely.

Juan Caballero: this could perhaps be called an “ergonomic” or “developer experience” argument, since “oh wait i’m storing linked documents wrong” is a more helpful error message than “signature failed”.

Juan Caballero: even if, functionally, they’re the same outcomes.

Brent Zundel: The solution we are discussing and that has been discussed in the past is the proposal that if an issuer elects to protect the integrity of the context through the related resource property, we should add a requirement that a verifier must verify the integrity of the context.
… The change that is being proposed, “If that’s done, the verifier must check”.
… Dave has pointed out that in this particular this, that may be moot.
… How do folks feel about requiring that the verifier validate the integrity if the issuer specifies it? This would elevate SHOULD to MUST for resource integrity protection.
… Whether or not it directly addresses the issue doesn’t matter. On the one hand, it’s a general thing that makes sense to folks. On the other hand, it makes the people that raised the issue to be happy.

Benjamin Young: I think we need to separate the “why” because this is not enhancing the security and is adding processing cost.
… If we restrain it to context files, forcing people to process related resources may be OK, but I don’t believe that the expense of verifying all related resources (e.g., a PDF that is not actually used) can be expensive.
… It does not enhance security. We should be clear on why we’re doing it and at what cost.
… Right now, I don’t think the origin of the idea is not addressed by the idea itself.

Manu Sporny: +1 to what Benjamin said. As long as it’s optional for issuers for contexts, that seems like it would be acceptable to verifiers.
… Again, a successful attack has not been demonstrated.
… We are creating the expectation that can trip up developers where contexts are required to be validated but other related resources are not.

Ivan Herman: The only thing I could add to that is that I think we should do it, and we should draw attention to the fact that issuers should treat this feature with care because of the high cost to verifiers.

Dave Longley: Something that would make a lot of sense to me to propose that if your application reads the related resource field, it must check the hash.
… If you are going to read the related resource and there is a hash, you must check it.

Dmitri Zagidulin: @dlongley - that’s really elegant. it fits with what Benjamin/bigbluehat was saying (that we don’t need to /automatically/ check the URLs), but if you DO dereference/fetch.. yeah.

Benjamin Young: It’s possible now. You can do this now. Your implementer can use related resource. We added language saying that you can do that.
… My point is that making it a MUST or stronger than it is now is necessary.

Brent Zundel: The part of it that was clarified for me is that, if you are planning to dereference the URL, you MUST check it. I think that’s a very sane thing to add to the spec.

Juan Caballero: +1 to brent.

Michael Jones: As I see it, related resource is a security feature. It makes no sense, if it is present, to not require it as a security feature.

Brent Zundel: I think we’re at the point where we can entertain language for the proposal.

Manu Sporny: Proposed language.

Brent Zundel: Proposal is to add this language to the specification to address issue 272, raise as PR and close 272.

Michael Jones: Not OK with the beginning part. I think the way it should be worded is that, if something is listed in the related resources list, its integrity must be checked.

Brent Zundel: What if it says, “If it makes use of a resource…”?
… If there are resources there that a verifier is never going to touch, is it necessary to verify anyway?

Manu Sporny: e.g., What happens if I like to a 5GB video? I don’t need to check it unless I actually access it.

Dave Longley: +1 to manu, it’s a bigger security problem to force downloads.

Dave Longley: it’s also a privacy problem.

Dmitri Zagidulin: +1.

Manu Sporny: I’m concerned about VCs that link to lots of other documents. That could create a DoS attack on verifiers.

Dmitri Zagidulin: Agreed with Manu. Another nuance is that the other reason to not say that if it’s there it must be verified. If it’s cached, it should not need to verify it again as it already has a local copy.

Michael Jones: I get the 5GB video example. That’s not the motivating case. What we’re talking about are the contexts that are going to be a few kB. To partially address the issue, we should say that if the related resource is a context issue, it must be checked.

Benjamin Young: We could use language like “activate”. For example, the subresource spec for HTML doesn’t process them until they’re used.
… Context files can be quite large, e.g., schema.org.
… Maybe there’s better language as you might have it on hand.

Kevin Dean: Back to the question of there being multiple context files that are not known to the verifier.

Juan Caballero: +1 to bigbluehat - aligning with SRI language or other WG precedent sounds good.

Dave Longley: +1 to Kevin.

Kevin Dean: It’s not that you’re going to process them because you don’t understand them, those context files are irrelevant for the verifier, no need to download them. I don’t see any issue with the idea that if you’re not going to use it, you’re not going to check it.
… Caching might be considered verified if its already verified and cached. If there is content integrity on something you’re going to use, you don’t need toverify it. I don’t think we need to call out contexts as a type of file, because there are some that you will not use.

Gabe Cohen: I’m struggling to understand the use case where it’s there but not going to be used.

Dave Longley: to answer Gabe, in the three party model, you don’t know what verifiers will use and what they won’t.

Dave Longley: and different verifiers can make different choices.

Dmitri Zagidulin: @gabe - no, it’s more like, the VC is gonna be useful to many parties. SOME parties will actually use the video. and some won’t. doesn’t make it less legitimate.

Dave Longley: +1 to dmitriz.

Gabe Cohen: if some will use it then it should be verifiable.

Michael Jones: I’m fine with if you’re verifying something you already have cached you don’t need to verify again. If something is listed in a context, are you free to not use the context? I thought that there are context things that have non-local effects so you have to look at all contexts.

Benjamin Young: To the question about JSON-LD, in broader JSON-LD land, there are moments and times where you need to get all context files, cached or not.
… If you don’t use terms from another context file, you don’t need to retrieve it.
… There’s no way to know that unless you signed with data integrity. If I have a pile of context files and you give me a signature over the set of the quad, if I run things through a separate process and get the same hash from the same graph, then I don’t need the context files.
… As long as it maps to the same URLs, I can get the same signature.
… As long as your quads are signed, which is what data integrity is about, you’re fine.
… I get that what data integrity gives you is the signed quads, but the issue description gives the attacker the ability to change the meaning.
… It doesn’t change the semantic meaning. The quads you would get out would not succeed.

Dave Longley: and you must never read a mapping you don’t understand – securing the contexts does not “fix it”.

Dave Longley: (because that’s not the problem… the problem is reading terms from a context you don’t understand, which must never be done).

Dave Longley: (you must translate to context you do understand firsT).

Michael Jones: I have tried to bring all of this to Tobias to weigh in again.

Brent Zundel: I feel we are on the cusp of a decision.
… Mike, you’re the only one to object to the proposed wording.

Michael Jones: What is the current proposed resolution wording?

Denken Chen: I would like to propose that libraries be updated to check all the information in the VC. We are at the early stage of VC adoption. If we don’t enforce that in standard libraries… I propose discussing the boundary of safety boundary. To me, vc standard should be self-consistent in terms of chekcimg integrity of all information within the vc itself. That’s a great security improvement.

Kevin Dean: In answer to question about why have resources you don’t reference… gernreric credential could have image, you’re not interested in image, jut want name and address.

Dave Longley: +1 KevinDean.

Gabe Cohen: My question is, should we support issuing credentials that some verifiers may not be able to verify? Should we allow verifiers to not verify related resources? I will not block resolution.

Brent Zundel: Current proposal is as above.

Shigeya Suzuki: +1 decentra_.

Brent Zundel: Other language includes “if the verifier makes use of the resource…”.

Denken Chen: If we don’t, libraries developers out there might not check it at all.

Benjamin Young: Revision proposed.

Dmitri Zagidulin: @decentra_ - re issuing credentials that some verifiers may not be able to verify – that happens ALL the time though. for example, if a verifier just doesn’t support the signature algorithm. can’t verify.

Denken Chen: …that’s for the safety of the standard, for the rest of the world.

Shigeya Suzuki: @dmitriz I don’t think that is the normal case.

Ivan Herman: +1.

Greg Bernstein: +1.

Dmitri Zagidulin: +1.

Paul Dietrich: “a related resource property” or “the related resource property”?

Brent Zundel: If there’s language that would change your -1 vote, let us know.

Dmitri Zagidulin: it should be ‘a’, yeah.

Kevin Dean: +1 to “a” instead of “the”.

Paul Dietrich: +1.

Jay Kishigami: +1.

Denken Chen: +1.

Proposed resolution: add the following text to VCDM 2.0 to address DI Issue 272: If a verifier makes use of a resource listed in a relatedResource property, it MUST check the content integrity of the resource as specified in a relatedResource entry. (Brent Zundel)

Manu Sporny: +1.

Gabe Cohen: +1.

Wesley Smith: +1.

Ivan Herman: +1.

Brent Zundel: +1.

Greg Bernstein: +1.

Benjamin Young: +1.

Kevin Dean: +1.

Dave Longley: +1.

Denken Chen: +1.

Jay Kishigami: +1.

Dmitri Zagidulin: +1.

Paul Dietrich: +1.

Shigeya Suzuki: +1.

Will Abramson: +1.

Juan Caballero: +1.

Michael Jones: 0.

Juan Caballero: i kinda liked “activate” but that can always be a followup PR if anyone wants to bikeshed.

Resolution #2: add the following text to VCDM 2.0 to address DI Issue 272: If a verifier makes use of a resource listed in a relatedResource property, it MUST check the content integrity of the resource as specified in a relatedResource entry.

Manu Sporny: I will raise a PR for this.

Brent Zundel: It’s lunchtime.

Manu Sporny: There are three proposals related to data integrity to look at tomorrow.

Paul Dietrich: Brent, can you confirm the time for tomorrows meeting?

4. Resolutions