Re: Streamlining Data Integrity Cryptosuites

I think this is an interesting direction (related to discussion in 
https://github.com/w3c/vc-data-model/pull/759), but I have the following 
observations:

1. The example on slide 6 about Ed25519Signature2020 and 
JsonWebSignature2020 feels a bit unfortunate, since the two suites 
actually differ in more than just the "type". The former uses 
"proofValue" whereas the latter uses "jws". A better example might be 
Ed25519Signature2020 and EcdsaSecp256k1Signature2020.

2. If the main idea of this proposal is to move the crypto suite type 
into a string and align everything else as much as possible, then isn't 
this to some extent re-inventing what we already have with 
JsonWebSignature2020?

3. I'm not sure if the DataIntegritySignature will really be applicable 
to 80% of the cryptosuites. For example, on slide 9 you mention 
"bbs-2022" as a potential "cryptosuite" string value, but my 
understanding of the whole BBS+ work is that it can sometimes require 
additional properties such as "requiredRevealStatements", which would 
then create a need for an addition JSON-LD context anyway to define that 
extension. I feel like other ZKP approaches and other future proof types 
may also involve additional extension properties that won't be 
completely covered by DataIntegritySignature.

4. What about public key types and specs that depend on them (DID Core)? 
Do you envision something similar there, i.e. move the key type into a 
string value?

Markus

On 31.07.22 16:47, Manu Sporny wrote:
> Hi VCWG (bcc: CCG),
>
> Now that the VCWG work is under way and the CCG Data Integrity
> specification has been selected as the input document for the Data
> Integrity work, it's time to start nailing down some implementation
> directions for the next 2+ years.
>
> One of the first of those considerations is streamlining the way we
> build Data Integrity cryptosuites. Please find a proposal attached to
> this email that:
>
> * Ideally, eliminates the need to create new JSON-LD Contexts for
> cryptosuites for 80%+ of the use cases we currently have.
>
> * Continues to ensure the ability to get large compression gains via
> the use of semantic compression (e.g., CBOR-LD)
>
> VCWG Chairs, this is a request for some time on a future call to
> discuss this proposal and get VCWG buy-in on the concept given that it
> will significantly impact the cryptosuites that we standardize in the
> group.
>
> -- manu
>

Received on Sunday, 31 July 2022 15:32:16 UTC