Re: Selective Disclosure

>Are the technical details of the Kiva protocol and directed identifiers
publicly available?

Not yet, we participated in a paper discussing decentralized identity which
will talk more about what we have put together and that paper should be out
soon I believe. However, we're focused on getting our pilot project
delivered and adjusting based on what we learn from that before we
open-source the code and expose more of the tech. In my opinion, the tech
itself isn't as interesting as how it fits into the working implementation
in the Sierra Leone context and how well it serves the citizens of Sierra
Leone.

>How much interoperability is Kiva willing to have with W3 standards?

We started going down this path after finding the DID spec
https://w3c-ccg.github.io/did-spec/ and have tried to follow the iterations
of it and the related new specifications to ensure what we are building
follows the standards. That's a primary goal, though of course we'll have
to see with the final implementation.

On Mon, May 20, 2019 at 9:34 AM Ian Smith <ian@vidicode.pro> wrote:

> How much interoperability is Kiva willing to have with W3 standards?
>
> On Sat, May 18, 2019 at 12:11 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
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
>