Re: selective disclosure without ZKP

Hi all,

Workday does selective disclosure without ZKPs. Our approach is documented here: https://github.com/workdaycredentials/specifications/blob/master/specifications/claim-proof.md


Simply put, we sign over each attribute individually on issuance. It has suited our disclosure needs thus far.

Gabe

From: Tobias Looker <tobias.looker@mattr.global>
Date: Wednesday, June 10, 2020 at 9:13 PM
To: Nikos Fotiou <fotiou@aueb.gr>
Cc: "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Subject: Re: selective disclosure without ZKP
Resent-From: <public-credentials@w3.org>
Resent-Date: Wednesday, June 10, 2020 at 9:13 PM

Hi Nikos,

This is very interesting, we had explored this mechanism too however did not feel it fulfilled our privacy goals hence why we have been working on https://github.com/w3c-ccg/ldp-bbs2020<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c-2Dccg_ldp-2Dbbs2020&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=_nSjATs-7S6lEmkIJOl7Rg2kyOYDC8u9VLZqyWPbrSY&s=ZvWm82rQfGlNNCJW8MEiXhtMxOrf-kGNlyv2MlO0Zjs&e=> instead. Are you able to provide any benchmark estimates of your approach around signing, verifying deriving and verifying proofs? Also as wayne raised earlier in this thread are there concerns in your approach about a verifier being able to brute force the reveal of some of the un-revealed attributes in a proof? In any case we would be keen to collaborate in making sure there is commonality around how a selective disclosure scheme intersects with "linked data proofs", i.e we have defined a new algorithmic function known as derive proof, which takes in a JSON-LD document featuring a linked data proof and the reveal document, e.g the document defining what you would like to reveal from the original proof (this is a JSON-LD frame<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_json-2Dld11_-23dfn-2Dframe&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=_nSjATs-7S6lEmkIJOl7Rg2kyOYDC8u9VLZqyWPbrSY&s=27nO4CJbcact_N0B4368pz2YXrKz0w88anqSqwCNt4Q&e=> to prevent us having to define any new syntax here) and returns the resulting derived proof. Even just agreeing on this API for various selective disclosure schemes would be a great leap forward!

Thanks,
[Mattr website]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mattr.global&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=_nSjATs-7S6lEmkIJOl7Rg2kyOYDC8u9VLZqyWPbrSY&s=vAD7I-U2OarDDiv41h6ys7SsKS3gfzOTTcS7jYIxcsY&e=>

Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>
[Mattr website]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mattr.global&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=_nSjATs-7S6lEmkIJOl7Rg2kyOYDC8u9VLZqyWPbrSY&s=vAD7I-U2OarDDiv41h6ys7SsKS3gfzOTTcS7jYIxcsY&e=>
[Mattr on LinkedIn]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_mattrglobal&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=_nSjATs-7S6lEmkIJOl7Rg2kyOYDC8u9VLZqyWPbrSY&s=ZO_RSCpZGtZhX5CsWAjYKoJxS1GdorL0KOGEeY862WY&e=>
[Mattr on Twitter]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_mattrglobal&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=_nSjATs-7S6lEmkIJOl7Rg2kyOYDC8u9VLZqyWPbrSY&s=wUAxlexW-EoFsxNZSvLNup4wA99x02hAneJGB0dtGw4&e=>
[Mattr on Github]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mattrglobal&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=_nSjATs-7S6lEmkIJOl7Rg2kyOYDC8u9VLZqyWPbrSY&s=XlDwyKa-Q5FXMfOeJC0MFZ-dYDSOKPYZHTjwHdBDvuI&e=>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Thu, Jun 11, 2020 at 1:43 PM Nikos Fotiou <fotiou@aueb.gr<mailto:fotiou@aueb.gr>> wrote:
Indeed, if verifiers are colluding then you are losing the selectivity!

From: Daniel Hardman<mailto:daniel.hardman@evernym.com>
Sent: Πέμπτη, 11 Ιουνίου 2020 3:36 πμ
To: Nikos Fotiou<mailto:fotiou@aueb.gr>
Cc: public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: Re: selective disclosure without ZKP

I believe this is the technique that Workday has advocated and demoed at the Fall 2019 IIW. They may have more info.

Just to be clear: the merkle tree root hash is itself a perfect correlator; every credential will have a different value for it. If you have fields 1-10, you can do selective disclosure on any subset of fields 1-10, but you are *always* revealing field 11 (the merkle tree root hash) to every verifier. This may or may not be a problem, depending on your requirements -- but should be accounted for in the analysis of the selectivity benefit.



On Wed, Jun 10, 2020 at 5:39 PM Nikos Fotiou <fotiou@aueb.gr<mailto:fotiou@aueb..gr>> 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





This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.