Re: Selective Disclosure

https://github.com/w3c-dvcg/hashlink/

Has been useful for us working with the third option, as well as relying on
IPFS which provides some similar capabilities coupled with transport and
client implementations.

We built a p2p demo on top of Orbit DB (uses IPFS) which supported DID and
VC, but the code is very stale at this point (and we've taken down the
public IPFS node):

https://github.com/transmute-industries/transmute/tree/master/packages/transmute-did-orbit-db

Unfortunately, the user had to be online for the DID to be resolvable and
the credential to verifiable, if a verifier had not cached either, and
obviously relying on a cache for either is questionable, but there is not
much choice if the subject/holder is offline.

Also OrbitDBs permissions model is difficult to work with.

OS


ᐧ

On Fri, May 17, 2019 at 10:04 AM Dave Longley <dlongley@digitalbazaar.com>
wrote:

>
> 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
>
>

-- 
*ORIE STEELE*
Chief Technology Officer
www.transmute.industries

<https://www.transmute.industries>