Why serialize the baseProof and derivedProof values

[jeswr]

I'm trying to understand the need to serialise and parse proofValues in the ecdsa-sd-2023 functions. In particular, I am trying to understand the need for defining:

• https://www.w3.org/TR/vc-di-ecdsa/#serializebaseproofvalue
• https://www.w3.org/TR/vc-di-ecdsa/#parsebaseproofvalue
• https://www.w3.org/TR/vc-di-ecdsa/#serializederivedproofvalue
• https://www.w3.org/TR/vc-di-ecdsa/#parsederivedproofvalue

Which results in encoding a bunch of semantics within one literal value of the JSON-LD document; as opposed to making the proofValue take the form:

   ...
   proofValue: {
      baseSignature: ...,
      pubKey: ...,
      hmacKey: ...,
      signatures: ...,
      mandatoryPointers: ...,
   }
   ...

The string isn't encrypted, so it isn't for privacy - so the only other two justifications that I can land on are:

• compression or,
• the VC Data Model requiring string proofValues and not wanting to modify the spec given the current stage it is at in its lifecycle & the fact that there are existing implementations

[dlongley]

The details of the data produced by individual cryptographic suites were intentionally kept isolated / encapsulated from other application-specific data. This data is intended to be only consumed by the security layer and shouldn't be handled / managed by the application as individual components -- with a presumption that doing so might even some pose some security / privacy risk. A similar design is taken with the multikey expression of key material as a single block of bytes at the application layer vs. the alternative of directly expressing individual key components such as elliptic curve coordinates, private / public exponents, etc.

This approach is also somewhat informed by various efforts in the security community to add safer abstractions that expose only higher level APIs / direct data access. The idea is to improve on some of the problems that have occurred with other approaches that expose every low-level detail or element in the same layer as other application data or that exposed too many low-level interfaces without a clear indication of how their safe use depends on a particular composition. These low-level approaches have also had the drawback of the creation of superfluous, potentially incorrect, and highly specific validation code running at more layers (that should be agnostic to the data) than just the security layer.

So the approach is intentional and, regardless, you are correct that it's not something that could be changed at this stage of the process even if there were consensus to change it.

[msporny]

We should write up the reasoning in #329 (comment) in the Data Integrity specification (if we haven't done so already). I have transferred this issue from vc-di-ecdsa to vc-data-integrity.

[msporny]

PR #330 has been raised to address this issue. This issue will be closed once PR #330 has been merged.

[msporny]

PR #330 has been merged, closing.