- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 29 Jul 2023 11:11:58 -0400
- To: Christopher Allen <ChristopherA@lifewithalacrity.com>
- Cc: W3C Verifiable Credentials Working Group <public-vc-wg@w3.org>
Hey Christopher and Sam, apologies for the delay in response, last week was hectic. On Fri, Jul 21, 2023 at 10:31 PM Christopher Allen <ChristopherA@lifewithalacrity.com> wrote: > Is this fundamentally selective disclosure using hash-based ‘elision’? You'd have to define "hash-based elision" for me to give you a definitive answer, but I'll try anyway. :) From what I understand of Gordian Envelope and ACDC, no it's not hash-based elision. I say that with a huge caveat that my understanding of both is almost certainly not tracking the latest developments, and they differ in important ways. I believe ecdsa-sd is a different approach. The approach is outlined in this slide deck: https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit#slide=id.g2174b6c9183_0_1364 There are detailed examples of how it works on slides 18-25. Perhaps you could take a look and let me know if you agree that it's not an elision-based approach? Sam smith wrote: > The ACDC spec for some time has included similar mechanisms 1) nested partial disclosure and/or 2) arrays of blinded hashes for selective disclosure. To be clear, ecdsa-sd does neither due to information leakage concerns. We use a flat list of statements that only reveals structure when a selective disclosure is made and not before, and only then with the information revealed (which is not true for other mechanisms like SD-JWT). So, with ecdsa-sd, you don't accidentally discover the structure of information that is not disclosed. From what I remember, ACDC can do this for some structures (but not for sets/lists). I don't know where Gordian is on this particular item. We don't encode arrays of blinded hashes because that can leak information (which is further elaborated upon, below). > So apparently, there is some convergence to using collections of blinded hashes as standard cypto enabled selective disclosure mechanisms. I wouldn't say that, there are drawbacks to using collections of blinded hashes, which I touch upon above and elaborate upon below. > I wasn’t aware of anything possible other than that which is NIST compliant as BBS+ & CL sigs both requires pairing cryptography. Yes, the ecdsa-sd approach does not require pairing-based cryptography... it uses boring old NIST-compliant cryptography. The steps are roughly: 1. Convert the input document into canonical statements (RDF canonicalized quads). 2. Split the quads into one "mandatory disclosure set" and multiple "selective disclosure statements". 3. Generate an ephemeral NIST-compliant keypair. 4. Sign the "mandatory disclosure set" and the public component of the ephemeral key using your public DID (or whatever public NIST key you want to use). 5. Individually sign each "selective disclosure statement" with the ephemeral private key, and then throw the private key away. 6. Bundle all the signatures together; that's your initial proof. Attach the signature to the document using the generalized Data Integrity "add proof" algorithm, and hand it over to the holder. The holder can then take that document, with the attached initial ecdsa-sd proof, and generate derived proofs (selectively disclosed VCs) to give to verifiers. > The link to the PR wasn’t that helpful, no details or docs in it. The PR contains links to the slide deck, the specification text, and one complete implementation, which has a lot of documentation related to the usage of the library. I'll re-produce those links below: Presentation on Selective Disclosure for W3C Data Integrity https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit# ecdsa-sd specification text: https://pr-preview.s3.amazonaws.com/w3c/vc-di-ecdsa/pull/20.html#ecdsa-sd-2023 ecdsa-sd-2023-cryptosuite library usage: https://github.com/digitalbazaar/ecdsa-sd-2023-cryptosuite/blob/main/README.md > Is this proposal a hash of an LD quad list (aka a “quin”) or some other technique? The "mandatory disclosure set" is a single hash and signature of a set of quads. Each "selective disclosure statement" is individually hashed and signed. There is also an HMAC that is used as a randomization function to prevent leaking information via bnode identifiers. This information leakage prevention mechanism is a feature that is missing from other selective disclosure techniques when dealing with arrays of data (such as the number of employees in a company, or children in a family, or items in a shipping manifest, or other types of information leakage that you don't want when doing a selective disclosure). > Does it use a single salt ( i.e. like mDL) or can individual items be salted or unsalted depending on correlation requirements? There is no single salt value, as described above. The signatures themselves are correlatable because we're not using pairing-based cryptography. That said, it's possible to have multiple per-signature hashes and salts. We're looking for feedback on the current specification to see if we should add that functionality or not. It would provide some level of correlability protection as long as we can find the right NIST-approved primitives to do it. The challenge with this cryptography suite has been using only NIST-approved primitives, which limits the options we have wrt. anti-correlation primitives. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Saturday, 29 July 2023 15:12:39 UTC