Re-use proofValue from DataIntegrityProof instead of jws

[msporny]

We should discuss whether it's better to use proofValue from DataIntegrityProof instead of jws. There are upsides and downsides to both approaches. We might also explore if JsonWebSignature2020 should be renamed to JsonWebSignature or DataIntegrityProof.

[mprorock]

We might also explore if JsonWebSignature2020 should be renamed to JsonWebSignature or DataIntegrityProof

+1

[msporny]

Here are a few options.

The first is an attempt to re-use DataIntegrityProof, which would require encoding some sort of flattened JWS JSON Serialization into proofValue and prepending a multibase u value for base64url encoding. Upside there is that it fits nicely into the DataIntegrityProof format and benefits from CBOR-LD compression (if that's viewed as a benefit). Downside is that it is not 1) a detached signature, which is what implementations do today, 2) uses a u prefix, so it's not a raw output from a JWS library.

{
  "type": "DataIntegrityProof",
  "cryptosuite": "jws-2022",
  "created": "2022-11-29T20:35:38Z",
  "verificationMethod": "did:example:123456789abcdefghi#keys-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "uDtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q"
}

The second option is to try and add a multibase encoding e for "JOSE-encoded dot notation", re-use proofValue, which feels like a horrible abuse of the multibase registry. The upside is that we can largely keep all the code the same, just change jws to proofValue and we're done, though you wouldn't get CBOR-LD compression w/o writing a JOSE compressor. Feels like an abuse of both multibase and CBOR-LD.

{
  "type": "DataIntegrityProof",
  "cryptosuite": "jws-2022",
  "created": "2022-11-29T20:35:38Z",
  "verificationMethod": "did:example:123456789abcdefghi#keys-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..MJ5GwWRMsadCyLNXU_flgJtsS32584MydBxBuygps_cM0sbU3abTEOMyUvmLNcKOwOBE1MfDoB1_YY425W3sAg"
}

The third option is to loosen the restriction on proofValue to allow the use of jws, which might be the right balance to strike. We'd have to loosen restrictions on proofValue here:

{
  "type": "DataIntegrityProof",
  "cryptosuite": "jws-2022",
  "created": "2022-11-29T20:35:38Z",
  "verificationMethod": "did:example:123456789abcdefghi#keys-1",
  "proofPurpose": "assertionMethod",
  "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..MJ5GwWRMsadCyLNXU_flgJtsS32584MydBxBuygps_cM0sbU3abTEOMyUvmLNcKOwOBE1MfDoB1_YY425W3sAg"
}

I'm leaning towards option 3, unless someone else can think of a better way of taking advantage of proof and DataIntegrityProof being defined in the base vc/v2 context? I haven't spent a lot of time thinking about this, so there might be a better approach.

/cc @dlongley

[OR13]

I've added a label to track changes that we would make based on data integrity, we can make them before it stabilizes, but I prefer to just wait and gather a larger group to do all at once.

[msporny]

I've added a label to track changes that we would make based on data integrity, we can make them before it stabilizes, but I prefer to just wait and gather a larger group to do all at once.

As a related aside, I'm hoping to simplify the text that needs to be written in cryptosuite specs and will provide an example w/ the new eddsa-2022 cryptosuite. That should make Editor's lives easier with the vc-jws-2022 cryptosuite if/when you apply some of the Data Integrity spec changes to it.