Re: Selective Disclosure for W3C Data Integrity

This was my weekend project (inspired by ecdsa-sd)

https://github.com/transmute-industries/vc-di-sd

It's basically the same as ecdsa sd except for the proof format.

Instead of multiformats and cbor, it uses JSON, JWS, and JWKs.

As a side note, the "proof" is also a valid JWKS, since json members that
are not understood are ignored.
There are no undefined terms in the proof, since they all carry the
"proofValue" and must be deleted before integrity is checked.

It uses URDNA2015 to canonicalize the data, so it is vulnerable to certain
attacks when schema validation is not performed, but wherever possible it
verifies signatures before attempting to canonicalize.

It also supports all the registered JWS algorithms, so you can plug it into
any remote kms with software / hardware isolation that can't get off RSA,
or ES256.

Most of the trouble I experienced was understanding how JSON Pointer and
JSON Frame are combined, and managing the sort order of n-quads.

There is huge amount of complexity embedded in ecdsa-sd that I think should
be removed:

-
https://github.com/digitalbazaar/di-sd-primitives/blob/main/lib/canonize.js
- https://github.com/digitalbazaar/di-sd-primitives/blob/main/lib/filter.js
- https://github.com/digitalbazaar/di-sd-primitives/blob/main/lib/pointer.js
-
https://github.com/digitalbazaar/ecdsa-sd-2023-cryptosuite/blob/main/lib/proofValue.js

Even though the verifiable credentials data model has a base media type of
`application/vc+ld+json`, ecdsa-sd requires RDF and CBOR dependencies.

The RDF dependency should be removed since you can canonicalize JSON with
JSON Pointer and JCS more efficiently, and JSON Pointer is already a
dependency.

The JSON Pointer bits of ecdsa-sd are probably its best feature.

The CBOR dependency is currently awkward, but should probably be kept and
COSE should be used instead of JOSE, that way you can pack all the
selective disclosure bits that are not integrity protected by the issuer in
the COSE unprotected header.

This would allow you to do selective disclosure over
`application/vc+ld+json` without first mapping / transforming to
`application/n-quads` and with compact binary signatures that support the
same registered algorithms as VC-JWT.

As a side note, I found this several orders of magnitude harder to
implement than sd-jwt, which only took a few hours... This ate up most of
my weekend, except for a brief wedding event... I am sad my HPKE project
was not able to be worked on.

BBS + CBOR will probably be much better than this approach in the end, but
since w3c verifiable credentials are stuck as JSON-LD, there is limited
ability to improve on the size / compactness front.

I think the W3C VCWG should really focus on canonicalization with JCS and
JSON Pointer because of this, we can get much better performance and
developer experience by building on RFCs instead of W3C TR that is not yet
finished, and which converts to a content type which we don't actually need
to secure, but which is automatically secured when `application/vc+ld+json`
is secured.

Regards,

OS

On Sat, Jun 3, 2023 at 11:51 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Wed, May 31, 2023 at 8:37 AM Richard Spellman
> <richard.spellman@gosource.com.au> wrote:
> > I think the challenge, going back to my point, is less about business
> practice, and more about usable abstractions.... the underlying protocol
> exchange would look like two agents engaging in presentation exchange where
> the requesting verifier initiates the request, and the holder agent
> constructs the presentation based on the query. A human observing the
> interaction could still think about it in the same terms, but that
> abstraction should not drive the underlying exchange...
>
> Yes, exactly. To make your suggestion concrete, there is an example of
> this in the Selective Disclosure for Data Integrity slide deck (slide
> 16):
>
>
> https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit#slide=id.g2446ba3ea2c_0_41
>
> That effectively asks the Holder: "I need an Employee Credential
> stating your employers name."
>
> The way that works via the Verifiable Presentation Request spec is
> that only the claims that are needed are requested by the Verifier.
> The Holder's software then interprets the request and will attempt to
> find the minimum selective disclosure that could be performed to
> fulfil the request.
>
> For example, if the individual has an Employee VC that is signed (in
> parallel) using both ecdsa-2019 and ecdsa-sd-2023, and both parties
> know how to handle ecdsa-sd-2023 signatures, then the digital wallet
> can provide such a limited disclosure to the Verifier (exposing only
> the employer's name and only the parts of the ecdsa-sd-2023 signature
> that matter).
>
> The Holder would only be exposed to a simple question on what the
> Verifier is requesting, and could then consent to the information to
> be released to the Verifier.
>
> So, +1 to your "usable abstractions" statement, Richard. This is very
> much about usable abstractions and your thought process on the matter
> is aligned with ours.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>