[Cfrg] ZKP for proving ownership of a credential

Manu Sporny <msporny@digitalbazaar.com> Wed, 03 June 2015 02:18 UTC

Return-Path: <msporny@digitalbazaar.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832E31B32B7 for <cfrg@ietfa.amsl.com>; Tue, 2 Jun 2015 19:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.596
X-Spam-Level: ***
X-Spam-Status: No, score=3.596 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxO2osbmHn8U for <cfrg@ietfa.amsl.com>; Tue, 2 Jun 2015 19:18:07 -0700 (PDT)
Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E5D1B29E2 for <cfrg@irtf.org>; Tue, 2 Jun 2015 19:18:07 -0700 (PDT)
Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.84) (envelope-from <msporny@digitalbazaar.com>) id 1YzyFn-0001gR-VN for cfrg@irtf.org; Tue, 02 Jun 2015 22:18:05 -0400
Message-ID: <556E63DB.8090904@digitalbazaar.com>
Date: Tue, 02 Jun 2015 22:18:03 -0400
From: Manu Sporny <msporny@digitalbazaar.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Crypto Forum Research Group <cfrg@irtf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 192.168.100.5
X-SA-Exim-Mail-From: msporny@digitalbazaar.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000)
X-SA-Exim-Scanned: Yes (on mail.digitalbazaar.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/IOR3xSBOx3TvppVbIrZgDQ2nkyU>
Subject: [Cfrg] ZKP for proving ownership of a credential
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 02:18:09 -0000

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_f3Ikz1opQ/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. 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/