Add proof configuration canonicalization to algorithm steps

[Wind4Greg]

For the cryptosuite: eddsa-2022 I updated the algorithm sections with one small editorial fix and missing steps of "proof configuration canonicalization" (prior to hashing). The changes are summarized below.

• In section 3.1.3 Transformation (eddsa-2022). Don't need both (3) Set output to the value of canonicalDocument. and (4) Return canonicalDocument as the transformed data document. These amount to the same thing. So removed old step 3.
• In section 3.1.5 Proof Configuration (eddsa-2022). We need to add the @context field and canonize the proofConfig. I called this canonicalProofConfig
• In section 3.1.4 Hashing (eddsa-2022). Update to use canonicalProofConfig

Note that the proof verification steps are incomplete with regard to reconstruction of the proofConfig to be canonized and hash. This seems to affect section 3.1.2 Verify Proof (eddsa-2022), which refers to section 3.1.7 Proof Verification (eddsa-2022), which refers back to [VC-DATA-INTEGRITY] specification, Section 4: Algorithms which is incomplete in this regard.

---

Preview | Diff

[msporny]

This might be the wrong thing to do, because it'll pull in all sorts of contexts that don't have anything to do with the data integrity proof. It's also unnnecessary if you're using something like the VC v2.0 context and is unnecessary when using something like a JCS-base canonicalization (that encapsulates JSON-LD). IOW, this step interplays in ways that are shaky for non-JSON-LD solutions.

There are a couple of code paths we have to think about here:

1. You are NOT doing a JSON-LD-to-RDF canonicalization, which means you don't need to do anything with @context.
2. You are doing an JSON-LD-to-RDF canonicalization, but the existing @context has the necessary data integrity term mappings (such as the VC v2.0 context).
3. You are doing an JSON-LD-to-RDF canonicalization, and the existing @context DOES NOT have the necessary data integrity term mappings (e.g. you're signing a vanilla JSON-LD document). In this case, you want to be surgical in what you pull in (just the data integrity v1 context). In this case, should we add the data integrity v1 @context to the proof or at the top level of the document?

/cc @dlongley @davidlehn @gkellogg

[Wind4Greg]

This is only an attempt to resolve the issue of the missing steps to get a hash of the proof configuration in the cryptosuite: eddsa-2022 case. For JCS this is not needed. For the current two cases that use RDF canonicalization something is missing in the draft. I think I saw this in a couple implementations and it validates against CHAPI playground.

Requiring a specific context be used can work to.

[w3cbot]

iherman marked as non substantive for IPR from ash-nazg.

[msporny]

Normative bug fix, reviewed, no objections, merging.