Re: Privacy enhancing/protecting credentials

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

Received on Thursday, 4 June 2015 14:17:09 UTC