Re: [Cfrg] ZKP for proving ownership of a credential

[Vadym Fedyukovych <[e-mail]>]

On Wed, Jun 03, 2015 at 02:33:43AM +0000, Paul Lambert wrote:
> 
> 
> On 6/2/15, 7:18 PM, "Manu Sporny" <[e-mail]> wrote:
> 
> >Hi all,
> >
> >I'm currently involved in some work in a Community Group at W3C called
> >the Credentials CG as well as the Web Payments Interest Group at W3C. An
> >executive summary of what the Credentials CG is trying to do is here:
> >
> >https://docs.google.com/document/d/1Nq543-Am1hQUIZ2hhzAFl8KexvIEBwDDc_f3Ik
> >z1opQ/edit
> >
> >We have a subset of credentials, like proof of citizenship ("this person
> >is a citizen of the United Kingdom") and proof of age ("this person is
> >above the age of 21"), that we believe could be asserted without leaking
> >information that could be used by colluding websites* to identify the
> >individual with the credential. We're trying to avoid having a single
> >identifier associated w/ these credentials that can be used to track
> >individuals between sites.
> >
> >Clearly, at some point it's impossible to protect the privacy of the
> >individual or organization because information like a government issued
> >ID or name is shared in the credential. However, those are not the use
> >cases we're focused on with this particular question.
> >
> >We have a hunch that perhaps some form of Zero Knowledge Proof could be
> >used with the credential, such that:
> >
> >1. The issuer of the credential (a government) could issue a
> >   credential to a recipient (a citizen). The credential would
> >   contain an assertion (this person is a citizen of the United
> >   Kingdom). The credential would also contain a credential-specific
> >   ZKP algorithm and some public ZKP initialization vectors of some
> >   kind.
> >2. The recipient (the citizen) would separate out the /private/
> >   credential-specific ZKP algorithm and store it. The recipient
> >   would also store the /public/ credential with ZKP initialization
> >   vectors.
> >3. A verifier (3rd party website, like the BBC) would then request
> >   a credential proving UK citizenship.
> Unless the credential is different each time it is provided to a third
> party the recipient is trackable.

It depends on credential type.
This holds for a blind signature (u-prove) such that
recipient produces a challenge
verifiable with equality-of-two-logarithms relation.
This does not hold for a strong RSA -based credentials scheme.

> This problem has been ?solved' to some degree by P1609.2 for automotive
> applications.  
> 
> 
> Paul
> 
> 
> >The recipient and verifier
> >   would then go through a number of ZKP iterations until the
> >   verifier was satisfied.
> >
> >The end result is that the recipient has proven their citizenship while
> >the verifier has ensured that it checked this particular property of an
> >individual before delivering a service to them.
> >
> >Unfortunately, we don't have any experts in ZKPs in the group and need
> >to have a chat with someone that is an expert. Preferably, someone that
> >knows if it is possible to construct a ZKP that could be used in this way.
> >
> >If there is a more promising cryptographic approach than using a ZKP,
> >we'd love to hear about that as well. Any ideas?
> >
> >-- manu
> >
> >* The one big caveat to this is that a simple ask of an email address,
> >  browser fingerprinting, supercookies, defeats this mechanism.
> >  However, I believe our mandate in the future is going to be
> >  "don't make privacy worse on the Web".
> >
> >-- 
> >Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> >Founder/CEO - Digital Bazaar, Inc.
> >blog: Web Payments: The Architect, the Sage, and the Moral Voice
> >https://manu.sporny.org/2015/payments-collaboration/
> >