W3C home > Mailing lists > Public > public-credentials@w3.org > May 2019

Re: Selective Disclosure

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Fri, 17 May 2019 13:10:46 -0400
To: daniel.hardman@evernym.com, Kyle Den Hartog <kdenhar@gmail.com>
Cc: David Chadwick <D.W.Chadwick@kent.ac.uk>, W3C Credentials Community Group <public-credentials@w3.org>
Message-ID: <0526d03e-280b-8a23-b402-294c8f8199f7@digitalbazaar.com>

On 5/17/19 12:47 PM, Daniel Hardman wrote:
> I am under the impression that method ii (atomic credentials) and method 
> iii (hash) both require the signature to be disclosed. Even if you salt 
> the hash, the signature is a strong correlator. Am I right? If so, I 
> don't think salting the hash provides much value.
> 
> ZKPs allow you to reveal or not reveal a particular field--but the 
> particular piece of knowledge that is not revealed, ever, is the 
> signature in the original credential. You are proving in zero knowledge 
> that you possess a signature, without showing it. I think that in this 
> aspect the selective disclosure possibilities of ZKPs do not have an 
> analog in methods ii and iii.

It is true that they don't have exactly the same characteristics, but I
don't think that should preclude offering various options.

Yet another selective disclosure option would be a third party that
anonymizes the data and escrows it -- which I believe to be the most
viable option for preventing correlation whilst maintaining trust.

> 
> On Fri, May 17, 2019 at 8:41 AM 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 17:11:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:49 UTC