Re: FW: Selective Disclosure for W3C Data Integrity

Hi Luca, I like your write up and examples! Particularly your example 
where car mileages are exchanged/mis-represented. This has been a 
concern of mine with mechanisms that produce fine grained statements for 
signing.

I somewhat differentiate between mechanisms for efficiently signing a 
bunch of "atomic credentials", some of which may be disclosed, and 
higher level mechanisms/standards that control the 
"atomic-ness/bindings" of the claims.

For signing a bunch of "atomic claims" I see straightforward comparisons 
between Merkel Tree (like Open Attestation, Gordian Envelope), BBS, and 
"Individual Signing" (like DB's SD for Data Integrity).

For controlling the "atomic-ness" of statements. I'm not so sure. Might 
some JSON-LD tools help here? Hence why I wanted to see more example 
documents, especially once with multiple claims and nesting. I'm looking 
at a CLR example from Tracy Korsmo and you definitely don't want a 
student to be able to swap grades amongst courses in a presentation 
(like your mileage example).

Cheers Greg

On 6/7/2023 12:45 AM, Luca Boldrin wrote:
>
> 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>
>