Adopt an option to use JWSLinkedData Signature suite
Hello guys, thanks for the hard work on this project. I come here today on the behalf of GXFSFR to make a suggestion of an enhancement that we currently have and use in our authentication scenario using walt.id.
For a little bit of context, to secure a document, an unsecure document must be passed to a transforming algorithm, a hashing algorithm and then we can generate its signature based on a proof serialization algorithm. According to the W3C, it is the cryptographic suite that defines said algorithm (https://www.w3.org/TR/vc-data-integrity/#cryptographic-suites).
For the JsonWebSignature2020 (the signature suite used for example in compliance), while being deprecated to protect the integrity of VCs, it is also a suite that has been abandoned by the W3C (last report is from a year ago) and there are no clear definition of the full process of transforming / hashing the data such as for example in the EDDSA2022 Signature Suite (https://w3c.github.io/vc-di-eddsa/#transformation-eddsa-2022).
The process described in this draft on EDDSA2022 is also similar to one of the implementation of the data-integrity specs by DigitalBazar (https://github.com/digitalbazaar/data-integrity) which are the author of the spec, but also used in a linked-data signature library https://github.com/WebOfTrustInfo/ld-signatures-java.
The main difference between those libraries and the way we currently sign / verify in compliance is in the construction of the payload that is signed. In ldsign, in addition to normalize the payload without the proof, it also normalizes the proof (in which the VC context is added to allow normalization) but without the jws. Both normalization are hashed then concatenated in their byte format rather than hexadecimal(Proof hash + SD Hash). This method of signing adds another layer of security by protecting the proof option of the Verifiable Credential and could be an improvement for the current way of signing.
We already have an implementation on the gxfsfr-dev branch so if you are curious about how it is done you can find it there.
What do you guys think of adding a parameter that would allow users to use this way of signature / verification ? It could allow everyone to interact with the compliance using credential signed by solution based on those libraries and increase the interoperability of the compliance service.
Please let me know what you think of this proposal and don't hesitate to schedule a meeting with me (fr / eng ) if you want more explanation / demo