The Meta-Identity System

Let’s start with a question: “In the Identity Metasystem, how can Identity Providers Exist?”

It seems simple in principle; someone sets up an Identity Provider server which has a Web Services Security Token Service (STS) and a policy engine. The server invites “subjects” to create profiles (lists of identity attributes) and then creates signed tokens asserting those profiles for consumption by Relying Parties. All this is easy to do.

The Paradox of the Identity Provider

What’s hard is:

• Paying for the Identity Provider server and the service it provides.
• Convincing Relying Parties that they should rely on information provided by a third party (the Identity Provider) rather than maintaining identity attribute information themselves.
• Assigning liability when a relying party asserts that a claimed identity attribute is incorrect.
• Assigning liability when a subject claims that the wrong identity attribute claim was released to a Relying Party.
• Making subjects whole when a security failure “leaks” subject identity attributes directly from the Identity Provider.
• Assigning liability and making subjects whole when a security failure “leaks” subject identity attributes from a Relying Party.

There’s a vicious circle here. Relying Parties won’t want to outsource identification of their transaction partners unless they can feel sure that the Identity Provider’s information is better than their own, or unless they can be indemnified against losses arising from mis-identification. Identity Providers, therefore, have to spend a lot of money on data verification, or liability insurance, or both. But to spend a lot of money, Identity Providers need to make a lot of money. This means that either their fees or their transaction volumes need to be very high. To generate high fees and high transaction volumes, Identity Providers need to have a valuable asset. And (here’s the rub) if Identity Providers provide their subjects’ identity attributes to Relying Parties, they don’t have an asset - because they’re giving it away to their customers.

The Potemkin Village

Parenthetically, by giving identity attributes to Relying Parties, Identity Providers turn the Identity Metasystem into a kind of Potemkin Village - a false front hiding emptiness and weakness. The Identity Metasystem's subjects rely on the Identity Provider to safeguard their private information, but the Identity Provider can’t safeguard information which is sitting in Relying Party systems. Unless the Relying Party's systems change, the implementation of the Identity Metasystem does nothing to reduce the total privacy risk of the environment it’s introduced into - though it may increase Relying Parties’ liabilities for that risk, because the Identity Provider’s contracts may create liabilities for Relying Parties who mishandle the information they provide.

The Meta-Identity System

If this seems gloomy, there’s good news. The technical infrastructure of the Identity Metasystem contains the seed of a solution to both problems (“How does the Identity Provider make money?” and “How do we avoid building a Potemkin Village?”). That seed is metadata.

In order to build an asset, the Identity Provider has to stop giving its crown jewels - identity data - to its customers. It can do this simply by changing what it puts into the claims it hands out to Relying Parties. Instead of answering a Relying Party’s query “How old is Bob?” with the claim “Bob is 45”, it can answer “How old is Bob?” with the claim “Bob is over 18”. Instead of answering the query “Is Bob a good credit risk?” with the claim “Bob’s credit history is (fifty-page report goes here)”, it can answer “Is Bob a good credit risk?” with the claim “97% of people with credit histories similar to Bob’s repaid loans of under $200,000 on time.”

Claims like these contain metadata rather than data. From the point of view of the Identity Provider, identity metadata has two big advantages over identity data. The first advantage is that using identity metadata in claims allows the Identity Provider to provide a service to its customers without handing over its core asset - and in fact using identity metadata allows the Identity Provider to build the value of its asset by developing expertise in analyzing raw identity data and transforming it into more and more accurate and useful metadata.

The second advantage of using metadata instead of data is that it allows the Identity Provider to provide a service to Relying Parties while minimizing the disclosure of specific personal information to those parties - thereby reducing privacy risks to subjects. Once the Identity Provider gets out of the business of providing raw identity data, of course, it no longer makes sense to call it an “Identity Provider”; calling it an “identity metadata provider” sounds hopelessly geeky, though, so I propose instead to call it an “Identity Oracle”, since what it’s really doing is answering questions about an identity.

As a technical community and as a society, we can realize a lot of benefits by eliminating Identity Providers. Instead of building an Identity Metasystem with Identity Providers, we should build a Meta-Identity System with Identity Oracles. The technical infrastructure of the Identity Metasystem doesn’t need to be changed - all that needs to change is what we put in the claims and the way we think about the system.

I gave a talk about this at the recent Burton Group Catalyst Conference. The talk includes a lot of material I haven’t discussed here; if you’re interested in listening to the talk, the Burton Group has kindly posted it in podcast form here, along with the accompanying slides.