Re: Privacy enhancing/protecting credentials

As time permits look into

http://en.wikipedia.org/wiki/Zero-knowledge_proof

would love to engage, but ... v. time poor! :(

perhaps create a system for zero-knowledge proof of bearer credentials?

p.


On Thu, Jun 4, 2015 at 10:16 PM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 06/04/2015 09:47 AM, Adrian Hope-Bailie wrote:
>
>> This feels a lot like the issue around the sensitivity of payment card
>> PANs and the EMVCo tokenisation scheme that has been designed to resolve
>> the issue. While the problems are different the solutions feel similar.
>>
>> Would we want the ability to decouple the issuer from the entity that
>> generates the one-time-use credential (let's call it the anonymizer). So
>> one could have a federated flow where the recipient passes their
>> credentials to the anonymizer and this entity masks the sensitive
>> information and re-signs the credentials.
>>
>
> Yes, in the designs we've been discussing at Digital Bazaar, you can
> decouple the anonymizer service (what we've been calling it) from the
> issuer. These could, for example, be dedicated, trusted services that
> people use to obtain bearer credentials after providing them with a
> non-bearer credential.
>
> I'm still a bit concerned that we need to better define the threat model
> here. If we're worried about sites colluding to determine that an entity
> that visits two different sites is *the same entity*, I still believe the
> system could be easily defeated. So, I think we need to be clear about the
> problems we're solving with the added complexity.
>
>
>> The consumer must obviously trust the anonymizer and the issuer.
>>
>
> Yes. The issuer could also name that they trust a particular anonymizer
> service and allow the trust to be chained that way.
>
>
>> In some respects this is not unlike how ApplePay works with tokens
>> representing payment cards.
>>
>> On 4 June 2015 at 15:28, Manu Sporny <msporny@digitalbazaar.com
>> <mailto:msporny@digitalbazaar.com>> wrote:
>>
>>     One set of use cases that keep coming up are privacy enhancing
>>     credentials. Specifically, can the ID that's associated with a
>>     credential be used to track an individual between colluding sites (the
>>     answer is clearly, yes). So, we've engaged the Cryptography Forum
>>     Research Group[1] in an attempt to discover the most cutting edge ways
>>     of establishing trustworthy credentials that are also privacy
>>     protecting:
>>
>>     http://www.ietf.org/mail-archive/web/cfrg/current/msg06864.html
>>
>>     We've also launched a research initiative at Digital Bazaar to look
>> into
>>     this space in more detail. We have a number of workable solutions that
>>     we're looking at right now. They primarily revolve around creating a
>> way
>>     to automatically re-issue a short-lived bearer credential that is not
>>     associated with an ID. Here's how the most promising solution we've
>> come
>>     up with could work:
>>
>>     Definitions
>>     -----------
>>
>>     'bearer credential' - a short-lived one-time use credential (5
>> minutes)
>>     that is not associated with an identity that "proves" that the holder
>> of
>>     the credential has been verified by the issuer as having a valid
>>     credential.
>>
>>     Credential Flow
>>     ---------------
>>
>>     1. An issuer issues a long-lived credential to a recipient. The
>>         credential has information in it on how to acquire a
>>         short-lived 'bearer credential'.
>>     2. When a consumer asks the recipient for a credential, the
>> recipient's
>>         software notices that the credential could be provided in an
>>         'anonymous' fashion using a 'bearer credential'. The recipient is
>>         asked if they'd like to protect their privacy by using the
>>         'bearer credential'.
>>     3. The bearer credential is transmitted to the consumer, which
>> verifies
>>         that the digital signature from the issuer is valid.
>>
>>     The issuer always has the option to reject bearer credentials if
>>     pseudo-anonymity isn't desired on their end.
>>
>>     This mechanism could be built into a browser's "Incognito mode" such
>>     that only bearer credentials can be used in "incognito mode".
>>
>>     This is just a heads-up that we're looking into it and have a few
>>     solutions that we think may be workable.
>>
>>     -- manu
>>
>>     [1] https://irtf.org/cfrg
>>
>>     --
>>     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/
>>
>>
>>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>
>