Re: Selective Disclosure for W3C Data Integrity

https://github.com/w3c-ccg/Merkle-Disclosure-2021/tree/main/packages/linked-data-proof
(ancient
demo)

https://github.com/transmute-industries/merkle-proof

I would not recommend using these though, the latest related work is
happening in the COSE / SCITT WGs at IETF.

OS


On Mon, Jun 5, 2023 at 12:59 PM Greg Bernstein <gregb@grotto-networking.com>
wrote:

> I’ve seen the salted hash approach in SD-JWT to prevent “verifier to
> verifier” collusion (tracking) with fairly arbitrary signature algorithms.
> If we are just interested in ECDSA then we should be able to use the
> “random version of ECDSA” rather than the “Deterministic ECDSA” to achieve
> the same functionality without the need for a salt.
>
> Was just writing up a PR on “security considerations” for ECDSA
> Cryptosuite v2019 <https://github.com/w3c/vc-di-ecdsa> and while
> recommending Deterministic ECDSA left the option for random ECDSA.
>
> Is there a reference for the “salted hash tree” approach?
>
> Cheers
>
> Greg B. Grotto Networking <https://www.grotto-networking.com>
>
> On 6/3/2023 6:48 PM, Steve Capell wrote:
>
> Thanks Manu
>
> Happy to participate in these tests and calculations
>
> I can see how ecdsa-sd could be sufficient efficient (pending test results).  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?
>
> 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
>
> Steven Capell
> Mob: 0410 437854
>
>
> On 4 Jun 2023, at 1:41 am, Manu Sporny <msporny@digitalbazaar.com> <msporny@digitalbazaar.com> wrote:
>
> On Wed, May 31, 2023 at 4:48 AM Steve Capell <steve.capell@gmail.com> <steve.capell@gmail.com> wrote:
>
> Regarding the size / cost volumetrics I don’t have concrete metrics but I’ll say it’s not uncommon for trade documents like invoices and waybills to have dozens or even hundreds of lines.
>
> The reason I asked is because it would be nice if we could run some
> tests w/ ecdsa-sd and your supply chain use cases. Here are some
> situations where Data Integrity for Selective Disclosure (ecsda-2023)
> will work out well:
>
> * You have a large document with many claims (100+) that must be
> mandatorily disclosed (these are all lumped into a single hash in
> ecdsa-sd and so costs little), and only a few (1-30) that you want to
> be selectively disclosed (and only a few of those are disclosed at a
> time -- this costs about 66 bytes per revealed claim).
>
> * You have a small document with a handful of fields (1-30) that you
> want to be selectively disclosed (and only a few of those, 1-5, are
> disclosed at a time -- again, 66 bytes per revealed claim).
>
> For the Data Integrity for Selective Disclosure work, we are working
> on a Google Sheet that allows you to input the total number of
> statements, total number of mandatory disclosure claims, total number
> of selective disclosure claims, total number of objects without
> identifiers, and it will spit out the initial proof size, and then the
> selective disclosure proof size (based on how much you're disclosing).
> Having something like that for your merkle-based mechanism, SD-JWT,
> and BBS would be useful to the community. We'd prefer if each
> community provided the calculations, but if that doesn't happen, we
> might just put something out there and see how well we did at
> analysing the cryptographic variables. We're happy to be told we're
> wrong in order to get to more accurate numbers for the ecosystem to
> compare/contrast.
>
> -- 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>