Re: Selective Disclosure for W3C Data Integrity

On Sat, Jun 3, 2023 at 9:48 PM Steve Capell <steve.capell@gmail.com> wrote:
> Happy to participate in these tests and calculations

Great, we'll be in touch (via this mailing list) as we put together
some data models on initial signature size vs. selectively disclosed
signature size.

> I can see how ecdsa-sd could be sufficient efficient (pending test results).

Perhaps. If you can give us an example of a VC that has the sorts of
qualities that you feel are important? Perhaps a hundred-plus line
item invoice, waybill, or conformance certificate? You tell us the
mandatory disclosure fields and the selectively disclosed ones. That
would be a good place to start.

> How would we address the requirement for any holder along the supply chain to redact? Can you see a way to blend the salted hash tree model with ecdsa-sd?

Now that is something that ecdsa-sd will almost certainly not be able
to help w/ in its current form. ecdsa-sd was designed for use cases
where you're not going to be revealing more than a handful of
selectively disclosable claims and have no need for downstream Holders
to have the ability to further redact claims from the original set.
Others should correct me if I'm wrong here, but you'd probably only be
able to do that via a salted merkle tree approach (which is why what
you're talking about is a compelling feature, IMHO).

So, presuming that the salted merkle tree approach is an ecosystem
requirement, it would be fairly easy to slot it in beside ecdsa and
ecdsa-sd. We could call it ecdsa-redaction (or hopefully something
better?). The nice thing about Data Integrity is that it allows these
different signature mechanism/formats to co-exist with one another
through the use of cryptographic layering:

https://w3c.github.io/vc-data-integrity/#agility-and-layering

One could call these things "parallel signatures" as well (we're
looking for feedback from the community on what to name this design
pattern).

This approach is contrasted with the external proofs approach, where
each signature is mutually exclusive to the other (unless you put yet
another wrapper around the signatures, and by doing that, you
duplicate the data in the signatures). It also creates zero-sum
outcomes -- you MUST pick either signature mechanism X /or/ Y, because
you can't choose signature schemes X /and/ Y.

This was most recently experienced by the VCWG in the zero-sum
discussion regarding VC-JWT, ACDC, and Gordian Envelopes. 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.

> I agree with Richard’s observation that when we stop trying to copy the paper then there’s potentially a lot less need for redaction - but I suspect we’re in for a longish transition period, particularly for supply chain documents like invoices, waybills, and conformity certificates

Yes, agreed. So, what's going to take more time -- transitioning the
supply chain industry to rework some of their data formats and then
get that deployed at scale, OR creating a new cryptographic format and
getting it standardized at a global level? I don't envy either path.
:P

One thing is for certain -- these things don't just happen, they take
concerted effort... and the concerted effort doesn't happen until
options are put on the table, which is what we're doing with ecdsa-sd
and Data Integrity, in general.

-- manu

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

Received on Sunday, 4 June 2023 12:59:27 UTC