Hi, @msporny @dmitrizagidulin @martyr280 @dlongley @brentzundel @Sakurann @iherman @philarcher @peacekeeper @pchampin!

We (@rhiaro and I) reviewed this in our W3C TAG 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?

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

Wonderful, thank you for the quick turn around on the review and your comments. Responses to your questions below...

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

Good, glad it was helpful. :)

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?

There are at least three mechanisms in play that the ecosystem utilizes to increase interoperability when multiple cryptosuites are in play.

Implement Multiple Cryptosuites

The first mechanism that verifier implementations typically use is implementing more than one cryptosuite to ensure that they are capable of verifying multiple types of common cryptosuites. For example, implementations will support both EdDSA and ECDSA cryptosuites. You can also see this in action in the pre-Candidate Recommendation test suites today. There are currently three independent implementations that support both the "ecdsa-2019" and the "eddsa-2022" cryptosuites, which use different key types, cryptography, and signature formats.

https://w3c-ccg.github.io/vc-di-eddsa-test-suite/#eddsa-2022%20cryptosuite%20(verifier) https://w3c-ccg.github.io/vc-di-ecdsa-test-suite/#ecdsa-2019%20cryptosuite%20(verifier)

These implementations will be able to verify signatures from either cryptosuite.

Parallel Signatures Using Multiple Cryptosuites

The second mechanism that issuer implementations can use is digitally signing a single payload using multiple cryptosuites in parallel. This approach is explained in the proof sets section of the Data Integrity specification and elaborated upon in the section on Proof Agility and Layering. Fundamentally, this mechanism increases interoperability by allowing a verifier to select from a variety of cryptosuite signatures on a single payload, increasing the chances that it can use at least one of the multiple signatures to verify the payload. When a verifier requests a payload through a protocol of some kind, it can convey which cryptosuites it supports to the sender (which can then select from the available cryptosuite signatures to ensure that it is sending a cryptosuite signature that the verifier can understand). For one mechanism that is used to convey supported cryptosuites, see the section on acceptedCryptosuites in the DID Authentication Query Format Verifiable Presentation Request protocol specification.

Reducing Cryptosuite Optionality

The third mechanism that is utilized by the Data Integrity specification is reducing the optionality that a developer could pick from. Some cryptographic systems expose quite a number of "tunable buttons and knobs" that, while powerful and flexible, can also expose developers without a background in cryptography to combinations of unsafe choices. Cryptosuite specification authors are urged to protect application developers by not providing a great deal of optionality to developers and picking sensible defaults for a given cryptosuite version.

While the three mechanisms described above are designed to increase interoperability, there is always the danger that there will be a large number of cryptosuites developed that do not interoperate (or are not widely developed). The group acknowledges this risk and believes that it's largely addressed by 1) developers picking cryptosuites that have been vetted by standards setting organizations, 2) national standards that require certain types of cryptography to be used, and 3) market forces that gravitate towards a small set of cryptosuites if there were to become a larger set that are implemented.

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

The argument for it is: "In order to increase interoperability, implementations need to be tested against a stable baseline that the specification authors and community agree to."

The argument against it was: "We don't want to conflate the people writing the specification with the people writing the tests. There shouldn't be a single test suite or community that is in charge of test suites in case the specification author is negligent or another community is doing a better job at testing."

The latter was certainly the minority opinion in the discussion, which happened a long time ago, so we might try to add that language back into the specification if the TAG were to recommend that we do that.

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

Thank you for that observation. :)

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?

Yes, the Data Integrity specification is meant to be a generalized data integrity technology and is not only applicable to VCs. This is mentioned briefly in a NOTE at the bottom of the Design Goals and Rationale section. You can apply it, today, to any JSON or JSON-LD payload, and to any RDF syntax payload with some trivial modifications.

When the work was proposed, it was suggested that we should focus on a narrow use case with well defined boundaries. The work was originally slated for a "Linked Data Security WG", but then retargeted to the Verifiable Credentials WG. If the v1.0 work is successful, a better home for the work would probably be a W3C WG that is dedicated to Data Integrity and other security technologies (such as Authorization Capabilities and privacy-preserving cryptosuites).

And have you thought about preceding work like XML signatures? If so, how does it feed into your thinking now?

Yes, XML Digital Signatures was studied at depth before embarking on the Data Integrity work, we speak to that in the Transformations section (especially in the issue at the very bottom of that section). We have attempted to take great care in avoiding the mistakes made during the XML Digital Signatures work, some of those include:

• DI does not allow stylesheets, DTDs, or schema languages that might modify the data that is signed -- XMLDsig had to deal with things like stylesheets, schemas, DTDs, namespaces, namespaced attributes and a variety of other items that also modified the XML structures being canonicalized and signed. There was no way to tell which was applied, in what order, to get the final canonicalization and signature.
• DI does not allow variations of the information model to be signed -- XMLDsig had to deal with transformations such as XSLT, which affected the construction of the XML tree in ways that were not easy to predict nor clear which version/evaluation of the XML tree should be/was signed.
• DI uses simpler signed formats (NQuads or JSON) and DOES NOT modify text value strings. We rely on NQuads (for RDF) or JSON (for JSON) as the final canonicalized format which does not inherit any of the more complex internal text node canonicalization rules that XML DSig had to deal with, such as performing internal XML text node canonicalization for whitespace, line endings, charset encoding, word wrapping and specialized escape sequences.
• DI ensures composability by separating the syntax (JSON) from the data model (JSON or RDF) from canonicalization (JCS or RDFC) and signing/verification (ECDSA, EdDSA) -- A number of XML implementations bundled these steps or the signature mechanisms with the toolchain (because the toolchain processed the data model in a way that impacted the signatures, so bundling was the easiest way to guarantee stable signatures) making it impossible to compose different processing and securing mechanisms.
• DI protects the entire payload -- Variations of XMLDSig also allowed partial-signing of data where the headers were signed, but the content was not, leading to security vulnerabilities.

There are other smaller lessons learned from XMLDSig that impacted the work on Data Integrity, but the ones above are the biggest take-aways that we have considered.

Thank you, again, for the review and your time. It is very much appreciated! :)

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.