AnonCreds v2 + Data Integrity -> Demonstrated path to convergence

On Mon, Jun 5, 2023 at 4:10 AM Daniel Hardman <daniel.hardman@gmail.com> wrote:
> I just wanted to chime in to say that I appreciate the careful approach to this important topic. Kudos to Dave and Manu and crew.

Thank you Daniel, that means a lot given your background and
experience in the space. It is also a good segue to something I
alluded to in the previous Selective Disclosure for Data Integrity
thread. More below...

Manu wrote:
>> I'll highlight this in an upcoming email about an exciting new convergence w/ the AnonCreds v2.0 folks and Data Integrity -- where Data Integrity was leveraged to allow us to put to rest a many-year-long conflict between the two approaches.
> Steven Capell wrote:
> That’s very interesting.  And fairly immediately relevant. We will very likely face pilot scenarios where a single supply chain includes all three types and so we’ll be forced to play nicely together.

During the Verifiable Credential API calls over the past two weeks,
Patrick St. Louis (of Digital Identity Lab of Canada) and Stephen
Curran (Cloud Compass, Sovrin Foundation, and Province of British
Columbia) demonstrated something that is quite extraordinary.

They demonstrated a full round trip implementation of CL Signatures as
a W3C Data Integrity Proof. All the way from issuing, to presentation,
and verification. This was the first time, to my knowledge, that we've
seen such a thing implemented and with a few tweaks, I believe it can
be fully compliant with the upcoming W3C VC 2.0 and Data Integrity
standards.

One of the challenges that AnonCreds has had over the years was not
being NIST compliant (even if some of the components used are NIST
compliant), and therefore, not being able to be used for some "big
government" and "big enterprise" use cases. That story tended to
detract from the capabilities that CL Signatures brought to the table
(unlinkability, range proofs, link secrets, etc). Some moved on and
have placed their hopes on BBS, which suffers from the same "not NIST
compliant" issue (and isn't as capable as CL Signatures, by design).

Every Data Integrity cryptosuite that the VCWG is working on, save for
one (BBS), is built on NIST compliant cryptography. So, why is BBS
getting a free pass when CL Signatures didn't?

The thing that's different this time around is that we have a feature
in Data Integrity called "cryptographic layering" (also called
"parallel signatures"). The feature lets you digitally sign the same
data using more than one type of cryptography. For example, with this
Data Integrity feature, you can digitally sign a trade document using
ECDSA (which is NIST-approved), and in parallel, digitally sign the
same trade document using BBS, or CL Signatures (which are not
NIST-approved).

What this enables is both digital signatures to live along-side the
document, peacefully co-existing, and which one is used is up to the
Holder and Verifier to decide. Government verifiers might only accept
the ECDSA-signed version, while enterprises that are more innovative
(when it comes to use of new cryptographic features) could choose to
accept the latter.

The feature above is important because it doesn't put communities on a
collision course when it comes to which cryptographic mechanism one
has to choose. It no longer has to be an A /versus/ B decision...
instead it turns into a choice to support A /and/ B (and C, and D, and
E, if the use case calls for that many types of parallel signatures).

So, you could have one data payload that is secured in the following ways:

1. ecdsa (NIST compliant, with no ability to selectively disclose)
2. ecdsa-sd (NIST compliant, with the ability to selectively disclose)
3. bbs (not NIST compliant, but supports SD and unlinkability)
4. anoncredsv2 (not NIST compliant, but supports SD, unlinkability,
range proofs, SD, etc.)
5. postquantum (some NIST compliant post-quantum scheme in call
everything above fails)

All without having to re-encode the VC 5 times, re-issue the VC 5
times, or keep track of 5 different versions of the same data (with
different signatures) in a digital wallet.

Given how tense some of the discussions around W3C specs, CL
Signatures, and AnonCreds have been in the past, I'm happy to finally
see a path that doesn't put these important communities on a zero-sum
collision course with each other. What's more important is that we now
have a solution that enables faster iteration cycles on new
cryptography while also ensuring, in parallel, a baseline that's
NIST-compliant.

The demo that Patrick did (and presented to the AnonCreds community
last week) can be found here (starting at 9 minutes in):

https://meet.w3c-ccg.org/archives/w3c-ccg-vcapi-2023-05-23.mp4

and here (starting at 17 minutes in):

https://meet.w3c-ccg.org/archives/w3c-ccg-vcapi-2023-05-30.mp4

It's worth a watch if you're interested to see how NIST-compliant and
future-facing crypto that is pre-NIST compliance can live side-by-side
by using the W3C Data Integrity specifications.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Monday, 5 June 2023 13:26:05 UTC