Update selective disclosure functions and their use in ecdsa-sd sign, derive, verify.

[dlongley]

This PR updates the underlying selective disclosure functions to remove the need to use the JSON-LD framing primitive and to remove the special treatment of credentialSubject for VCs. It accomplishes this by using JSON pointers for selection (filtering and grouping) and skolemization of expanded (and subsequently compacted) JSON-LD documents instead of direct skolemization of N-Quads. Grouping and filter functions have been removed and replaced with a single canonicalizeAndGroup function, and the previous jsonPointersToFrame function has been adjusted to selectJsonLd as it now performs selection directly on skolemized, compact JSON-LD documents instead of producing a frame as an intermediate step.

The formats / expression of proof data in ecdsa-sd is unchanged, only the internals used to implement it are updated.

A few other corrections were made around label factory function production.

Some editorial clean up still needs to be done around the use of <var>, <em> and quoting variables using backticks, but this is not a new issue.

---

Preview | Diff

[Wind4Greg]

This is a nice improvement to the internal selective disclosure processing (both mandatory reveal, and selective reveal) to remove the dependency on JSON-LD framing. Key functionality is encapsulated in the canonicalizeAndGroup function.

It should be noted that besides the ECDSA algorithms from FIPS-186-5 (2023) that the EdDSA algorithms (Ed25519, Ed448) can be used. In addition the SD primitives particularly canonicalizeAndGroup maybe applicable for applying BBS to VCs.

[dlongley]

@TallTed,

Thanks heaps! So I applied all of your suggestions except for the (5) ones that changed the use of "and" when talking about passing parameters. Those suggest using "with" instead and I'm not sure that "with" is better?

Without that suggestion we have examples like this:

Use algorithm X, passing foo as A and B.
Use algorithm X, passing foo as A, bar as B, and C.

With that suggestion it would read like this:

Use algorithm X, passing foo as A with B.
Use algorithm X, passing foo as A, bar as B, with C.

I'm not sure what the consensus is, but "and" reads better to me. I can how the use of "with" reads alright when C is for example "any custom options":

Use algorithm X, passing foo as A, bar as B, and any custom options.
vs.
Use algorithm X, passing foo as A, bar as B, with any custom options.

But "and" still reads better to me personally and is consistent. Thoughts?

[TallTed]

Maybe...

Use algorithm X, passing A, and foo as B.
Use algorithm X, passing A, foo as B, and bar as C.
Use algorithm X, passing A, foo as B, and bar as C, along with any custom options.

[dlongley]

@TallTed,

Maybe...

Use algorithm X, passing A, and foo as B.
Use algorithm X, passing A, foo as B, and bar as C.
Use algorithm X, passing A, foo as B, and bar as C, along with any custom options.

I'd be fine with that, but I'm also fine to just leave it as always using "and". If you want to adjust your suggestions accordingly, I'll add them in -- or you can approve as-is. Just let me know.

[TallTed]

Revised the passing ... and vs passing ... with

[dlongley]

@TallTed,

Thanks again! I've applied all your suggestions. Two of them don't actually change the text anymore so the UI doesn't allow me to apply them, but ... they don't change the text so there's nothing to do anyway.

[Wind4Greg]

Hi Dave working on high level test vectors. Noticed redundant step to canonize proofOptions in section 3.5.3 Base Proof Hashing (ecdsa-sd-2023), this is already done in at the end of section 3.5.4 Base Proof Configuration (ecdsa-sd-2023) -- step 9.

[dlongley]

@Wind4Greg,

Since there's considerable reworking done in this PR and still some editorial clean up to be done later, I'd like us to get this merged and then work off it as a baseline. That should include any simplifications like you mentioned.

[msporny]

Normative, multiple reviews, changes requested and made, no objections, merging.