May 02, 2007
Selective Disclosure and Privacy

Often, when we're asked for "identification," it's not because the asker needs to know everything about us, but because they need to verify one aspect of identity: that I'm over 21, for example, if I'm trying to buy a drink. But since I don't have an "over 21" card that the bar can verify connects to me, I'm forced to give them my driver's license, from which they can also glean and store other data. Online, it doesn't have to be that way.

Builders of identity-management systems can design in stronger protections for their users' privacy, giving people a separate virtual "card" for every transaction, with only the necessary data included. Ben Laurie has written a good concise overview, Selective Disclosure, explaining how zero-knowledge proofs let us make verifiable assertions without giving away the store.

I claim that for an identity management system to be both useful and privacy preserving, there are three properties assertions must be able to have. They must be:

  • Verifiable
    There’s often no point in making a statement unless the relying party has some way of checking it is true. Note that this isn’t always a requirement - I don’t have to prove my address is mine to Amazon, because its up to me where my goods get delivered. But I may have to prove I’m over 18 to get alcohol delivered.
  • Minimal
    This is the privacy preserving bit - I want to tell the relying party the very least he needs to know. I shouldn't have to reveal my date of birth, just prove I’m over 18 somehow.
  • Unlinkable
    If the relying party or parties, or other actors in the system, can, either on their own or in collusion, link together my various assertions, then I’ve blown the minimality requirement out of the water.

While digital signatures are widely used for verification, the same signature on each item is a privacy-busting linkage. With the help of third parties and selective disclosure proofs, however, we can make assertions that are minimal and don't leave a trail. We can create digital one-time cards each time we're asked for a facet of our identities.

These properties fit well with legal principle of narrow tailoring. Limiting the identification provided to that required limits spillover effects and opportunities for misuse ("mission creep"). An ID-check law shouldn't become a source of marketing information; an online purchase needn't be an entry in a growing retailer profile -- unless that's an explicit choice. We might even be more willing to give accurate information in places like online newspaper sign-ins if we knew that information could never be added to or correlated with profile data elsewhere.

The next hard part, of course, is getting those with whom we do business to accept less information where they've been accustomed to getting more by default, but at least if we build the identity technology right, it will be possible.

Posted by Wendy at May 02, 2007 01:34 PM | TrackBack
Comments

This sounds a lot like the Internet2 Shibboleth project to me:

The Shibboleth software implements the OASIS SAML v1.1 specification, providing a federated Single-SignOn and attribute exchange framework. Shibboleth also provides extended privacy functionality allowing the browser user and their home site to control the Attribute information being released to each Service Provider. (http://shibboleth.internet2.edu/)

To briefly address the points you quoted:

Verifiable
Verification is based on a formal trust framework -- either a bilateral trust between the identity provider and the service provider or as part of a trust federation of which both the identity provider and the service provider are members.

Minimal
Shibboleth excels in this area. The user and/or the user's identity organization can decide what attributes about an individual (that I am over 21 years of age or that I am a resident of Ohio) are given to the service provider.

Unlinkable
If a unique id is required by the service provider (say, for instance, to provide some site customization) the identity provider can provide an opaque string, called a "targeted ID", that is unique for user/service-provider pairing yet in no way reveals the actual identity of the user and is meaningless outside of the user/service-provider pair.

Posted by: Peter Murray on May 3, 2007 09:41 AM

Hello! Pretty nice site, wants to see much more on it! :)
Good bye.

Posted by: utekko on May 23, 2007 01:15 PM
Track-Backs
Post a comment
Name:


Email Address:


URL:


Comments:


Remember info?