Re: Privacy enhancing/protecting credentials

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.

The consumer must obviously trust the anonymizer and the issuer.

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