- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Fri, 17 May 2019 11:03:05 -0400
- To: Brent Zundel <brent.zundel@evernym.com>, Kyle Den Hartog <kdenhar@gmail.com>
- Cc: David Chadwick <D.W.Chadwick@kent.ac.uk>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
On 5/17/19 10:52 AM, Brent Zundel wrote: > I am already working on this for the implementation guide. I will add > the third method to my section on subjective disclosure, and welcome > feedback on the PR. (It is not complete, but I raised a PR for the > express purpose of obtaining early feedback). > https://github.com/w3c/vc-imp-guide/pull/14 When adding the third method, I recommend saying there are a number of potential mitigation strategies for the preimage attack/brute force problem, including using salts or VRFs (https://en.wikipedia.org/wiki/Verifiable_random_function). This is just so it's clear that we're not saying there's only one solution or that we're recommending any particular solution, rather that there is a problem for which some solution should be considered. > > On Fri, May 17, 2019, 08:41 Kyle Den Hartog <kdenhar@gmail.com > <mailto:kdenhar@gmail.com>> wrote: > > The third option is something I haven't heard of as an approach to > selective disclosure. I like the idea of adding both in as methods > of supporting selective disclosure in multiple ways. > > When writing specs to this do we highlight concerns with particular > approaches? Particularly one of the concerns I had with this is that > by sharing even a hash, it creates the potential for data to be > brute forced. This is easily solved with adding a salt and only > providing the salt when revealing the data. Would we want to include > something like this to heed potentially less private implementations? > > *Kyle Den Hartog* > Personal Blog <https://kyledenhartog.com> > > > On Fri, May 17, 2019 at 8:00 AM David Chadwick > <D.W.Chadwick@kent.ac.uk <mailto:D.W.Chadwick@kent.ac.uk>> wrote: > > Dear All > > selective disclosure is clearly an important feature of VCs, > e.g. for > driving licenses or passports we might only wish to reveal our > name and > nothing else. There are several potential ways of doing this, viz: > > i) use of ZKPs - zero knowledge proof algorithms allow > assertions to be > made about the VC, without revealing the VC itself > ii) use of atomic credentials - each property of the credential is > issued as a separate VC so that the holder can reveal individual > properties > iii) use of hashes - The VC only contains hashes of each of the > credential subject's properties, and the properties are > separately held > by the holder. The holder places the to-be-revealed property in the > Verifiable Presentation and the verifier computes its hash and > compares > it to the appropriate hash in the VC. > > Only the former is mentioned in the data model and neither of the > latter, whereas the latter 2 are less computationally intensive to > support and might be preferred by implementors. Can we add a > section on > this to the Implementors Guide > > thanks > > David > > > > > > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Friday, 17 May 2019 15:03:32 UTC