- From: Markus Sabadello <markus@danubetech.com>
- Date: Fri, 9 Jun 2023 21:23:08 +0200
- To: public-credentials@w3.org
- Message-ID: <b6a7553c-5ec4-7949-0db6-0cd7e430a947@danubetech.com>
Maybe Manu or Dave can clarify, but my understanding is that DB's "Selective Disclosure Data Integrity Cryptosuite" has bindings between all the claims and the credential, and would therefore NOT allow the re-composition of claims from different credentials as described in Luca's car mileage example. Markus On 6/7/23 18:17, Greg Bernstein wrote: > > 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> >>
Received on Friday, 9 June 2023 19:23:17 UTC