FW: Selective Disclosure for W3C Data Integrity

While I share the interest for selective disclosure techniques, I must admit that I still fail to see concrete scenarios where the “atomic credential” approach will not be up to the task (predicates are obviously excluded).  I tried to summarize my understanding here<https://medium.com/@luca.boldrin/atomic-credentials-and-selective-disclosure-6a9e0c791bdc> and would be glad to receive any feedback and pointers to use cases where atomic credentials wouldn’t be appropriate.
Thanks and best,
--luca


From: steve capell <steve.capell@gmail.com>
Date: Monday, 5 June 2023 at 22:42
To: Greg Bernstein <gregb@grotto-networking.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, Dave Longley <dlongley@digitalbazaar.com>, John, Anil <anil.john@hq.dhs.gov>, W3C Credentials CG <public-credentials@w3.org>, Richard Spellman <richard.spellman@gosource.com.au>, Sin Yong LOH <LOH_Sin_Yong@imda.gov.sg>, Ren Yuh KAY (IMDA) <KAY_Ren_Yuh@imda.gov.sg>
Subject: Re: Selective Disclosure for W3C Data Integrity
There’s a bit on the salted hash approach on this page https://www.openattestation.com/docs/docs-section/how-does-it-work/document-integrity<https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.openattestation.com%2Fdocs%2Fdocs-section%2Fhow-does-it-work%2Fdocument-integrity&e=fe314e73&h=61ee8f77&f=y&p=n>.  Written more from a developer user perspective than from a standards specification perspective - although I believe the Singapore team are writing it up as a specification.  Kay?  Is there a link for a draft specification on this?


On 6 Jun 2023, at 3:39 am, Greg Bernstein <gregb@grotto-networking.com<mailto: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://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Fw3c%2Fvc-di-ecdsa&e=fe314e73&h=982ea334&f=y&p=n> 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://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.grotto-networking.com%2F&e=fe314e73&h=e61414ab&f=y&p=n>

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><mailto:msporny@digitalbazaar.com> wrote:



On Wed, May 31, 2023 at 4:48 AM Steve Capell <steve.capell@gmail.com><mailto: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/<https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&e=fe314e73&h=e4d3f475&f=y&p=n>

Founder/CEO - Digital Bazaar, Inc.

https://www.digitalbazaar.com/<https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.digitalbazaar.com%2F&e=fe314e73&h=4c625816&f=y&p=n>

​
<OpenPGP_0x80179D68654AA86C.asc>