RE: selective disclosure without ZKP

Hi Nikos,

We currently have a scheme like this in production and you can read a quick write-up on it here: https://bloom.co/blog/how-does-share-kit-work/. We’re working on updating it to be more interoperable, but you might find it interesting as a demonstration of how it could work, including what the presentation proof looks like.

Some of the things I’d like to point out:

• We introduced ‘padding nodes’ into the tree, which are just nonsense data. This gives the user deniability about what they are choosing not to share. A verifier wouldn’t know if the concealed hashes are sub-credentials or padding nodes
• We added ‘auxiliary signatures’ to the sub-credentials in the tree. These signatures let users embed another DID into the presentation, that even the issuer doesn’t know about. This enables them to share the sub-credentials, proving they are the subject of the credential, but without the risk of correlation.

I believe there are better, more interoperable ways to accomplish this now, but thought you might find it interesting.

Thanks,
Isaac
On Jun 10, 2020, 8:36 PM -0400, Nikos Fotiou <fotiou@aueb.gr>, wrote:
> > . By "verifiable representation" did you mean verifiable presentation
>
> Yes!
>
> > In general it sounds like instead of putting the data directly into the VC, you'd like to put a reference to that data instead. Then, a verifier who can also access the data can check that the issuer authorized certain actions or statements related to that data. How close is this? Some examples would certainly help
>
> Not really. Suppose you have these two claims:
> name:”nikos fotiou”, age:”35”
>
> Instead of putting them directly in the VC you put:
> Hash( Hash(name:”nikos fotiou”) , Hash(age:”35”) )
>
> Where Hash is a hash function (e.g., sha-256) e.g.,
> …
> "credentialSubject": {
>     "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
>     "merkle_root": "43bfd3432……” //<-- this is the outer hash value
> }
> …
>
> Now I can disclosure my age in a verifiable way by  including in the verifiable presentation, in the proof section:
> Hash(name:”nikos fotiou”), age:”35”
>
> Any verifier can re-calculate the outer hash (included in the VC), hence it can verify the presentation, but it does not learn my name.
>
> Best,
> Nikos
>
>
> From: Wayne Chang
> Sent: Πέμπτη, 11 Ιουνίου 2020 2:50 πμ
> To: Nikos Fotiou; W3C Credentials CG
> Subject: Re: selective disclosure without ZKP
>
> Hey Nikos, thanks for sharing the idea. This is one of those questions where you'd probably need to specify the exact data structures and algorithms to make sure no one is misinterpreting your steps. By "verifiable representation" did you mean verifiable presentation, or is that something specific to your use case?
>
> In general it sounds like instead of putting the data directly into the VC, you'd like to put a reference to that data instead. Then, a verifier who can also access the data can check that the issuer authorized certain actions or statements related to that data. How close is this? Some examples would certainly help.
>
> Best,
> - Wayne
>
> On Wed, Jun 10, 2020, at 7:39 PM, Nikos Fotiou wrote:
> >
> > Hi,
> > We were thinking about VCs that support selective disclosure of claims without ZKP (we do not care about unlikability). A trivial approach that came up is the following: the issuer organizes all claims in a Merkle tree, includes the root of the Merkle tree (only) in the VC, and sends the VC and the tree to the holder. Then, the holder can include the VC and the corresponding Merkle membership proof in the verifiable representation.
> >
> > Does this sound reasonable?
> >
> > Best,
> > Nikos
> >
>
>