helge
November 21, 2023, 8:57am
1
Full title: W3C Invites Implementations of VC Data Integrity, Data Integrity EdDSA and ECDSA Cryptosuites, and VC JSON Schema
Deadline: 2024-01-23T23:00:00Z
Direct links to test suites:
This is relevant to FEP-8b32
2 Likes
EdDSA Cryptosuite test suite
You will need an issuer and verifier that are compatible with VC API and are capable of handling issuance and verification of Verifiable Credentials with DataIntegrityProof proof type using the eddsa-2022 cryptosuite.
Too complicated. I think I’ll skip that.
1 Like
helge
December 13, 2023, 8:35am
3
Just for my references:
opened 05:47PM - 01 Nov 23 UTC
_Note: I'm opening an issue here as there seems to be a plan to phase out https:… //github.com/digitalbazaar/jsonld-signatures/issues/178, but the problem we're facing concerns both libraries._
After having fixed an issue with jcs-based proofs not verifying properly in jsonld-signatures a few months back (https://github.com/digitalbazaar/jsonld-signatures/issues/176), I want to circle back to the issue of adding context definitions to the document and proof before signature generation. My concern is that the current praxis of altering @context properties during proof generation and verification may simply not be viable for proof mechanisms that directly sign the json representation of linked data.
Specifically, I see two issues:
1) Adding a proof (suite) specific context to the document can invalidate pre-existing proofs. This praxis is adopted both [in this library](https://github.com/digitalbazaar/data-integrity/blob/d9245721985f34703dde7a04aed13ca8dd80049e/lib/DataIntegrityProof.js#L386) as well as in [jsonld-signatures](https://github.com/digitalbazaar/jsonld-signatures/blob/567c8cf4479d2d8b6e65aa5e571c55d43573722b/lib/suites/LinkedDataSignature.js#L378). Adding, for the purpose of supporting a wider range of verifiers, a Ed25519Signature2020 to a document that has already been signed with a DataIntegrityProof using eddsa-jcs-2022 will alter the document, after which the eddsa-jcs-2022 suite will no longer verify the existing proof.
2) Adding the document context prior to signing and verification, as done [in this library](https://github.com/digitalbazaar/data-integrity/blob/d9245721985f34703dde7a04aed13ca8dd80049e/lib/DataIntegrityProof.js#L351) and, inconsistently (only on verification), [in jsonld-signatures](https://github.com/digitalbazaar/jsonld-signatures/blob/567c8cf4479d2d8b6e65aa5e571c55d43573722b/lib/ProofSet.js#L220) seems to be at odds with the prescribed proof configuration of existing jcs based cryptosuite specifications authored by Digital Bazaar (https://www.w3.org/TR/vc-di-eddsa/#eddsa-jcs-2022 & https://www.w3.org/TR/vc-di-ecdsa/#proof-configuration-ecdsa-jcs-2019). Even though this behaviour can be patched for digitalbazaar/data-integrity by reimplementing `createVerifyData` in your cryptosuite, jsonld-signature's behaviour will break verification in this case, which leads into a dilemma where implementing the specs correctly actually harms interoperability between implementations.
I'm hoping to start a thread here to discuss improvements that can be made to the way this is handled.
To kick this off, I can throw in two suggestions:
- Problem 1) could be solved by no longer requiring a proof/suite context to be present on the signed document; instead, this context could be added to the proof object where the document context does not already include it. From what I can see this model would continue to assure that all terms are defined and definitions are not redeclared.
- Problem 2) is probably easiest solved by aligning the proof configuration of jcs based cryptosuites with that of linked data proofs / rdf-based suites. Adding the document context to the proof object prior to canonicalization has no function for jcs-based proof schemes, but allows interoperability with the existing tooling without substantial changes to it.
Status of eddsa-jcs-2022 is in question.
1 Like