W3C home > Mailing lists > Public > public-credentials@w3.org > June 2020

Re: selective disclosure without ZKP

From: Wayne Chang <wyc@fastmail.fm>
Date: Wed, 10 Jun 2020 20:50:29 -0400
Message-Id: <b75646bc-fb21-42ab-bf34-4461cd558269@www.fastmail.com>
To: "Nikos Fotiou" <fotiou@aueb.gr>, "W3C Credentials CG" <public-credentials@w3.org>
Got it, echoing Dan's comments about the correlation risk here. If someone can see one of your hashes, they have a significant piece of the puzzle to relate it all together. I realize you did say that you didn't care about linkability, but there may be compounding attacks here too; the tree structure, if guessed correctly, could dramatically reduce the cost of brute forcing any particular node hash, for example if "age" is assumed to be a string representation of a number from 1-100. I think there could be use cases or encodings that would make this scheme more appropriate, but as a general solution there are some open questions.

Was there a specific use case you had in mind?

On Wed, Jun 10, 2020, at 8:34 PM, Nikos Fotiou 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 <mailto:wyc@fastmail.fm>
> *Sent: *Πέμπτη, 11 Ιουνίου 2020 2:50 πμ
> *To: *Nikos Fotiou <mailto:fotiou@aueb.gr>; W3C Credentials CG <mailto:public-credentials@w3.org>
> *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

>> 

> 

> 
Received on Thursday, 11 June 2020 00:50:43 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 11 June 2020 00:50:44 UTC