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

Re: Selective Disclosure

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Fri, 17 May 2019 16:24:10 +0100
To: public-credentials@w3.org, Verifiable Claims Working Group <public-vc-wg@w3.org>
Message-ID: <645505e6-4f8e-b959-3b3a-ae1a67f5714f@kent.ac.uk>
Its in the ISO draft for electronic driving licenses


On 17/05/2019 15:39, Kyle Den Hartog 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
Received on Friday, 17 May 2019 15:24:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 17 May 2019 15:24:40 UTC