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://www.openattestation.com/docs/docs-section/how-does-it-work/document-integrity>.  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> 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> <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://www.linkedin.com/in/manusporny/>
>>> Founder/CEO - Digital Bazaar, Inc.
>>> https://www.digitalbazaar.com/ <https://www.digitalbazaar.com/>
> 
> 
> <OpenPGP_0x80179D68654AA86C.asc>