Re: Selective Disclosure

Kevin,
Are the technical details of the Kiva protocol and directed identifiers publicly available? 
Thanks,
Vipin

> On May 18, 2019, at 2:10 AM, Kevin O'Brien <kevin@kiva.org> wrote:
> 
> This method of directed identifiers is what we are doing with Kiva Protocol, along with the hash method indicated in option iii.
> 
> It does complicate things to have to have a way to identify the directed identifier privately and us to have to hold some data which links the two, while keeping it private from who we are disclosing the signature to, but so far it is has looked doable.
> 
>> On Sat, May 18, 2019 at 12:33 AM David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
>> 
>> 
>> On 17/05/2019 17:47, 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? 
>> 
>> Not necessarily. If you use directed identifiers and SOP then you will
>> have different VCs for each verifier, and therefore different issuer
>> signatures and different VP signatures
>> 
>> David
>> 
>> 
>> > 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 <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
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>>