Re: Selective Disclosure for W3C Data Integrity

On Tue, May 30, 2023 at 12:03 PM Steve Capell <steve.capell@gmail.com> wrote:
> I’d like to suggest that it can and should live alongside your selective disclosure specification because it serves a different use case

Yes, the reality is that there are a number of emerging selective
disclosure/redaction schemes (DISD, SD-JWT, AnonCreds v2.0, JWP,
di-bbs) and each one has its benefits and drawbacks. There is a risk
that people in our community, and others, will prematurely jump in and
start doing zero-sum "apples-to-oranges" comparisons between the
different schemes... and it's easy to mislead, or be misled, about
what these schemes can and can't do.

All that to say, I agree with you... these things should "live
alongside" each other for long enough for proper implementation and
analysis to be performed (years). I know people want all of this stuff
to be done NOW, and some are rushing ahead and claiming that the
problem is solved, but the reality we're seeing on the ground is that
we're still early days with each of the approaches.

> [Singapore govt solution] serves a different use case

I can't speak directly to the use cases you cite without further
study. We did look at the salted hash approach and the use of merkle
trees for disclosures. Each had drawbacks that Dave outlined in his
post (and we'll outline later in an attempt at a fair comparison
between all the mechanisms). What would help us at this point is for
each selective disclosure scheme to publish a mathematical model of
some kind that lets you input total number of claims, number of
mandatory claims, number of selectively disclosable claims, and a
graph of how each changes based on those parameters. We have released
something equivalent to this in our slide deck at the beginning of
this thread. If we want to get to a fair comparison between the
mechanisms, those things will have to be produced.

> - removing a small number of commercially sensitive fields from otherwise quite large trade documents.  It’s much more efficient for this

Hmm, do you have an analysis that you could share that helps us learn
more about this? I'm not saying it's not true, I just don't have any
way to analyze the "much more efficient" claim.

Assuming that what you're saying is true, creating a Data Integrity
cryptosuite that does what you claim, and thus aligns w/ the W3C Data
Integrity approach, is entirely possible. Not only that, but the
design of Data Integrity is such that you are not forced to make an A
vs. B decision. With Data Integrity, because of parallel signatures,
you can choose A /and/ B. That is, you can issue a VC with parallel
signatures - regular ecdsa-2019, ecdsa-sd-2023, and ecdsa-merkle-202x.
We believe that this is one of the major benefits of Data Integrity --
it doesn't put different approaches on collision courses with one
another, as we saw with the VC-JWT, Gordian, and ACDC approaches
(external signature approaches).

> - allowing any holder who is usually not the subject to redact.  This is important because it’s usually a party further downstream in the supply chain that wants to redact a bearer-token style credential received from upstream.

I believe your statement above (even though I haven't done the
analysis). That's something we didn't design for in ecdsa-sd-2023, and
it's unlikely to be something that we add (unless it's easy, which I
doubt it will be). IOW, this might be the significant feature that a
merkle-based approach provides (the ability to delete paths through
the merkle tree as information is transmitted along the supply chain)
that cannot be achieved with the other selective disclosure
mechanisms.

In summary, I agree with you -- these things should live alongside for
a while and deeper analysis on benefits and drawbacks is needed. I'll
also note that Richard makes a very good point (that I'll try to
respond to next) about re-thinking how these VCs might be created to
reduce the need for cryptographic solution complexity. These selective
disclosure mechanisms are more complicated than plain old digital
signatures, so if we can simplify, we should.

What do you think of the above, Steve? Is it a reasonable way to
proceed with this particular class of work in the VC ecosystem?

-- manu

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

Received on Wednesday, 31 May 2023 08:20:50 UTC