Re: Selective Disclosure

I am also interested in the inclusion of the algorithm that is
intended for this in cryptography but the use cases are more narrow.
"Shamir Secret Sharing" is very good for cryptographically and
conditionally revealing data. I do not have an exhaustive list
prepared when zk-SNARKS would be more or less suitable than Shamir
Secret Sharing, but they are definitely alternatives and sometimes
supplement each other nicely.

For example, using Shamir Secret Sharing to give permissions based
access to any job recruiter that has openings for a certain field, and
then using zk-SNARKS to share sensitive information. Shamir's algo can
be used as a filter more than zk-SNARKS.

Ian Smith
Vidicode.Pro
360-551-7339

On Fri, May 17, 2019 at 9:36 AM Isaac Patka <isaac@bloom.co> wrote:
>
> We have a selective disclosure implementation in production which is similar to version iii outlined above. The spec is available here:
> https://github.com/hellobloom/specs/blob/master/attestation-data/Bloom-Merkle-Tree-22facf0b-bedb-4b45-bb7d-edcd57213eb0.md#selective-disclosure-merkle-tree
>
> And an example Verifiable Presentation using the spec is here:
> https://github.com/hellobloom/share-kit#example-1
>
> Some of the context fields are still placeholders and we need to update the subject identifiers to be DIDs instead of just Eth Addresses but we'd love to get more eyes on the spec and hear your feedback.
>
> Thanks,
> Isaac
>
> On Fri, May 17, 2019 at 11:25 AM David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
>>
>> Its in the ISO draft for electronic driving licenses
>>
>> David
>>
>> On 17/05/2019 15:39, 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 <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
>> >
>> >
>> >
>> >
>> >
>> >
>>

Received on Friday, 17 May 2019 16:18:25 UTC