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

Re: Selective Disclosure

From: Kyle Den Hartog <kdenhar@gmail.com>
Date: Fri, 17 May 2019 08:39:46 -0600
Message-ID: <CAKOFKS1ro320iZvLDtC9d740C87F_hdMwvUFriyCfscivHXmPw@mail.gmail.com>
To: David Chadwick <D.W.Chadwick@kent.ac.uk>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
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>
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 14:40:20 UTC

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