Re: Selective Disclosure

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.

On Fri, May 17, 2019 at 8:41 AM 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 <>
> On Fri, May 17, 2019 at 8:00 AM David Chadwick <>
> 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 16:48:08 UTC