Re: Selective Disclosure

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

On Fri, May 17, 2019, 08:41 Kyle Den Hartog <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>
> 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
>>
>>
>>
>>
>>
>>
>>