Re: Privacy enhancing/protecting credentials

Dear Dave,

I'm sorry to have raised issues already covered in the IETF (in this case
the Crypto Forum Research Group) -- my cpu's slows as I age! :(

Really glad you've already looked into ZKPs! :)

p.



On Fri, Jun 5, 2015 at 11:12 AM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

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