Re: Privacy enhancing/protecting credentials

On 06/04/2015 08:01 PM, Pindar Wong wrote:
> 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?

A credential wouldn't be a "bearer credential" if something other than
possession of the credential was necessary to establish ownership. The
"bearer" of a "bearer credential" is the /a priori/ owner of the credential.

That being said, before falling back to "bearer credentials", we were
exploring ZKP (zero-knowledge proof) solutions via discussions with the
Crypto Forum Research Group [1]. Unfortunately, we've found that one can
uniquely identify the recipient of a credential by using the parameters
necessary for a ZKP. This defeats our purpose here, which is to
establish pseudo-anonymity and prevent passive collusion that reduces
privacy.

Ultimately, we need to be able to establish the rightful owner of a
credential. We can either:

A. Base ownership on the mere possession of the credential itself (a
"bearer credential"). In this scenario, two identical credentials can be
owned by two entirely different entities. If you share the same
credential with two different parties, those parties can't use the
credential to determine if they are interacting with the same entity.
This is privacy-enhancing. Unfortunately, it also facilitates fraud; in
a digital world "bearer credentials" are easily transferred or duplicated.

B. Base ownership on something other than the mere possession of the
credential itself. In this scenario, two identical credentials must be
owned by the same entity, regardless of the mechanism used to establish
ownership. If you share the same credential with two different parties,
they can collude to identify you. This is privacy-diminishing. However,
fraud is greatly hindered.

We briefly explored a probabilistic approach to the problem using a
notion of "ownership pools" -- whereby an identical credential could be
potentially owned by some small number of recipients. While trying to
work out viability of the idea it quickly became clear that even if the
details could be worked out, we'd have a hard time proving it would
produce better outcomes than one that relied on simple, short-lived
"bearer credentials". It would, however, have much greater complexity.

As it stands right now, my view is that using very short-lived "bearer
credentials" is the best proposal. We can decouple "anonymizer" services
that produce these "bearer credentials" from the issuers of original
credentials to help ameliorate their need to be constantly online. This
requires that the anonymizer service be trusted by the consumer,
however, we can create a chain of trust by allowing issuers to state
trusted anonymizer services in the credential itself.

The downside to this is the added complexity and the need for online
access to anonymizer services in order to provide pseudo-anonymous
credentials to consumers.

1. http://www.ietf.org/mail-archive/web/cfrg/current/msg06864.html

> 
> p.
> 
> 
> On Thu, Jun 4, 2015 at 10:16 PM, Dave Longley
> <dlongley@digitalbazaar.com <mailto: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>
>         <mailto: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
> 
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Friday, 5 June 2015 03:13:06 UTC