#850: Specification review request for Verifiable Credential Data Integrity

Visit on Github.

Opened May 28, 2023

The Verifiable Credentials Working Group requesting a TAG review of Verifiable Credential Data Integrity and two Data Integrity Cryptosuite specifications (EdDSA and ECDSA).

These specifications describe mechanisms for ensuring the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs. Cryptographic proofs enable functionality that is useful to implementers of distributed systems. For example, proofs can be used to:

  • Make statements that can be shared without loss of trust, because their authorship can be verified by a third party, for example as part of Verifiable Credentials [VC-DATA-MODEL-2.0] or social media posts.
  • Authenticate as an entity identified by a particular identifier, for example, as the subject identified by a Decentralized Identifier (DID) [DID-CORE].
  • Delegate authorization for actions in a remote execution environment, via mechanisms such as Authorization Capabilities [ZCAP].
  • Agree to contracts where the agreement can be expressed as a digital signature that can be verified by another party.

Additionally, many proofs that are based on cryptographic digital signatures provide the benefit of integrity protection, making documents and data tamper-evident. The specifications in this review request enable these features in ways that were included in the W3C Verifiable Credentials Working Group charter.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: The VCWG is planning to take these specifications to Candidate Recommendation in September 2023 (at W3C TPAC), reviews before that time frame (ideally, by the end of July 2023) would be ideal.
  • The group where the work on this specification is currently being done: W3C Verifiable Credentials Working Group and W3C RDF Dataset Canonicalization and Hash Working Group
  • Major unresolved issues with or opposition to this specification:
    • Addition of unlinkable cryptosuite (in process)
    • Addition of selective disclosure cryptosuite (in process)
    • No registered opposition (no "intent to formally object" on any of the specifications)
  • This work is being funded by: The members of the W3C VCWG and W3C RCHWG that are actively participating in the development of these specifications including funding from the US Federal Government, the European Commission, and the Canadian Federal Government.

You should also know that...

  • This work intersects heavily with the Verifiable Credentials v2.0 work, which is also something that the TAG will be actively reviewing around the same time.
  • The W3C RCH WG is also doing some foundational work that these specifications rely on, and which TAG will be actively reviewing around the same time.
  • There is active work on selective disclosure cryptosuites and unlinkable digital signature cryptosuites, which are important to understand in order to get the full picture of what this work is attempting to achieve (on the whole).

We'd prefer the TAG provide feedback as:

☂️ open a single issue in our GitHub repo for the entire review

Discussions

2023-06-12

Minutes

we begin looking at the explainer

bumped to next week

2023-06-19

Minutes

bumped

2023-07-03

Minutes

bumped

2023-07-mos-eisley

Minutes

Hadley: are the cryptosuites normative dependencies?

Amy: the cryptosuite specs depend on the Data Integrity spec, but not the other way around

discussion of how RDF canonicalization fits in

Hadley: there's a json canonicalization process for plain json, and rdf canonicalization can be used if you have rdf

Amy: looks like they've considered complexity tradeoffs against the use cases they want to solve

looking at how cryptosuite specs fit with the data integrity spec.. data integrity specifies how to write a cryptosuite spec. Any cryptosuite can then be plugged in

The following language was deemed to be contentious: The specification MUST provide a link to an interoperability test report to document which implementations are conformant with the cryptographic suite specification.

The Working Group is seeking feedback on whether or not this is desired given the important role that cryptographic suite specifications play in ensuring data integrity.

Interested to hear more about both sides of that argument..

discussion about how this could be used as a general mechanism, and why it might be focussed on VCs (because it's impossible to charter a group for a general data integrity mechanism?). In the spec:

While this specification primarily focuses on Verifiable Credentials, the design of this technology is generalized, such that it can be used for non-Verifiable Credential use cases. In these instances, implementers are expected to perform their own due diligence and expert review as to the applicability of the technology to their use case.

We (@rhiaro and I) reviewed this in our virtual face-to-face this week.

First of all, we'd like to thank you for the clarity and conciseness of your explainer. Thanks!

The architecture which enables use of different cryptosuites depending on needs seems sensible. How does this affect interoperability? Is a verifiable claim from an implementation using one cryptosuite readable by an implementation using another?

We noted the contentious issue around requiring interoperability reports for cryptosuite specifications, and wondered what the different sides of the argument are for that.

We also see that you're not rolling your own crypto in this architecture and want to applaud that. Sensible choice. 

Also noting that the specification could be put to general use, rather than being suitable only for VCs. Have you considered how to expand this work for other use cases?  And have you thought about preceding work like XML signatures? If so, how does it feed into your thinking now?
2023-10-23

Minutes

Hadley: don't see any problems. Minor niggles on their response about use cases. Can easily see this being an opportunity for joining things up further down the line. Having said that it's hypothetical - no particular overlap they should be working on. Just makes me nervous about the self-imposed vaccum. Not concrete enough to put that back on the WG. We can sign this off.

2023-11-27

Minutes

Yves: only about defining some usable cryptographic capabilities. I think this one should be OK.

Hadley: the spec link they gave us was to a CR snapshot...

Yves: there are CR snaps and CR snapshots... It's been through the CR "gate".

<blockquote> Thanks for your extensive replies, @msporny.

We note that your process allowing a "verifier to select from a variety of cryptosuite signatures on a single payload" does improve interop, and we are happy to see that.

We have no further feedback on this particular review.

</blockquote>