What the Identity Oracle Isn’t

Blogger: Bob Blakley

Kim Cameron of Microsoft picked up the New York Times’ coverage of our LLP concept in a blog entry today.  His entry is generally excellent, but I’d like to pick on one little piece of it.  In the course of discussing the Burton Group’s identity concepts, Kim writes:

“Bob provides links to more resources, including one on Identity Oracles  - his sexy name for the  claims transformer generating “minimal disclosure tokens”.”

It’s important to be very clear here, so I’m going to say this pretty bluntly.  This statement is utterly and completely wrong.  An Identity Oracle is NOT a “claims transformer generating minimal disclosure tokens”.  It’s not even a claims transformer.  It’s not even a server.  It’s not even technology.

I’ve said twenty times from various stages and in writing on my personal blog and here that as long as we continue to try to solve privacy problems using technology, we are going to continue to fail, and the Internet will continue to lack an identity layer, and it will continue to be a privacy hazard.  Identity and privacy are not technology problems – they’re social, legal, and economic problems – and no technology can solve these problems.

The Identity Oracle is not a technology.  It’s a business.  Its business plan says “We allow people to enjoy the benefits of their identities while protecting them against the risks of misuse of their identities”.   It charges money for its services.  It works like this:

A human – let’s call him “Bob” – signs up for an account with the Identity Oracle.  The Identity Oracle collects some personal information about Bob, and signs a legally binding contract with Bob describing how it will use and disclose the information, and how it will protect the information against uses and disclosures which are not allowed by the contract.  The contract prescribes a set of penalties – if Bob’s information is used in any way which is not allowed by the contract, the Identity Oracle PAYS Bob a penalty: cash money.

When Bob wants to get a service from some giant, impersonal corporation (say “GiCorp”) whose business depends in some way on Bob’s identity, Bob refers GiCorp to the Identity Oracle; GiCorp then goes to the Identity Oracle and asks a question.  The question is NOT a request for Bob’s personal information in any form whatsoever (for example, the question is NOT “What is Bob’s birthdate”). And the Identity Oracle’s response is NOT a “minimal disclosure token” (that is, a token containing Bob’s personal information, but only as much personal information as is absolutely necessary for GiCorp to make a decision about whether to extend the service to Bob – for example a token saying “Bob is over 18”).

Instead, GiCorp’s request looks like this:

“I am allowed to extend service to Bob only if he is above the legal age for this service in the jurisdiction in which he lives.  Am I allowed to extend service to Bob?”

And the Identity Oracle’s response looks like this:

“Yes.”

The Identity Oracle, in normal operation, acts as a trusted agent for the user and does not disclose any personal information whatsoever; it just answers questions based on GiCorp’s stated policies (that is, it distributes only metadata about its users – not the underlying data). 

The Identity Oracle charges GiCorp and other relying-party customers money for its services.  The asset on the basis of which the Identity Oracle is able to charge money is its database of personal information.  Because personal information is its only business asset, the Identity Oracle guards personal information very carefully.

Because disclosing personal information to relying-party customers like GiCorp would be giving away its only asset for free, it strongly resists disclosing personal information to its relying-party customers.  In the rare cases in which relying parties need to receive actual personal data (not just metadata) to do their jobs, the Identity Oracle requires its relying-party customers to sign a legally binding contract stating what they are and are not allowed to do with the information.  This contract contains indemnity clauses – if GiCorp signs the contract and then misuses or improperly discloses the personal information it receives from the Identity Oracle about Bob, the contract requires GiCorp to pay a large amount of cash money to the Identity Oracle, which then turns around and reimburses Bob for his loss.

This system provides Bob with much stronger protection than he receives under national privacy laws, which generally do not provide monetary damages for breaches of privacy.  Contract law, however, can provide any penalty the parties (the Identity Oracle and its relying party customers like GiCorp) agree on.  In order to obtain good liability terms for Bob, the Identity Oracle needs to have a valuable asset, to which GiCorp strongly desires access.  This asset is the big database of personal data, belonging to the Identity Oracle, which enables GiCorp to do its business. And allows the Identity Oracle to charge for its services.

The Identity Oracle provides valuable services (privacy protection and transaction enablement) to Bob, but it also provides valuable services to GiCorp and other relying-party customers.  These services are liability limitation (because GiCorp no longer has to be exposed to private data which creates regulatory liability and protection costs for GiCorp) and transaction enablement (because GiCorp can now rely on the Identity Oracle as a trusted agent when making decisions about what services to extend to whom, and it may be able to get the Identity Oracle to assume liability for transactions which fail because the Oracle gave bad advice).

As long as we keep talking about “claims transformers” (which are computers) instead of “identity providers” and “identity oracles” (which are businesses) we are going to continue to build products nobody uses.  It’s not an accident that there are no commercial consumer identity providers today – no one is paying any attention to how such an entity would make money, and until investors know how they’re going to get paid, nobody is going to go into the Identity business.

The Identity Oracle is a business model for a service which provides consumer identities in a way which simultaneously protects individuals’ privacy and generates revenue for the business investor.  A claims transformer (which is a particular type of server) could be used to carry the “yes” and “no” tokens which the Identity Oracle transmits to its relying-party customers – but many other technologies could carry these “yeses” and “nos” too.  The Identity Metasystem technologies will be successful in the long term if and only if they enable successful business models – and the first step in this enablement is to stop pretending that building the technology is all that’s necessary to build the business.

You can see my original definition of the Identity Oracle here.

Comments

[Eric Norman]

One of the claims above is that nobody will go into the identity business (e.g. Identity Oracles and the like) unless they can make money at it.

Well, higher education seems to be fairly successful at being in the identity business by deploying Shibboleth and identity providers, which are almost the same as identity oracles.

Furthermore, higher education does not make money by providing testimony about identity information.

I'm not saying Bob is wrong; I'm just making an observation for folks to ponder and comment on.

I'll comment. I think it has a lot to do with liability. Higher education treats liability differently then the corporate sector.

[Bob Blakley]

Higher education isn't in the identity business. It's in the education business, and it needs to understand identity in order to be in that business. It offers identity to its students, and via Shibboleth to other educational institutions via federation.

It charges its students tuition; one of the services students get for their tuition is an identity provided by their institution, which can be used at the institution and its federation partners, but not outside that ecosystem.

My bank is happy to provide me an identity I can use with bank systems. It's also happy to provide me with a credit card I can use at merchants - provided that I pay a cut of each dollar spent to the bank in the form of interest fees.

A stated goal of the identity metasystem is to free me from the bondage to my bank (or my college) and give me an identity I can use anywhere. This will only happen if the provider of that identity can make enough money to do the management required to maintain it.

Another stated goal of the identity metasystem is to protect my identity - no matter who the provider is - against misconduct and negligence of relying parties who receive my information. Shibboleth accomplishes this by creating a trust relationship between my college and the other colleges I visit. This is a great model - one which I helped design. But it's not a model which consumers will get for free, without paying the equivalent of tuition to an Identity Oracle.

[Trey Tomeny]

This is my first notice of this Identity Oracle concept. It shares some characteristics with my idea for "Private Identity Providers" that are part of the "Private Identity Network".

My idea does have a way for identity providers to make lots of money- so I believe it may be a substantial step in the right direction.

Doc Searls visited my site the other day and left a comment, "...a great idea..." and featured it in a post on his personal blog and ProjectVRM blog yesterday.

Please check it out at replacegoogle.com if you are interested.

[Nishant Kaushik]

I agree that the business model for commercial Identity Oracles needs to be worked out. But I wouldn't underplay the need to develop the underlying technology component that makes this possible either. It wouldn't do to build the business case and find out that there are no tools to deliver the vision.

It is possible to stitch together a bunch of diverse technologies, and develop a management application on top of it to create such an online service. But that isn't repeatable. And there are a lot of parallels between the concept of an Identity Oracle business service and the Identity Services component that is needed for identity-enabled SOA applications (think 'Identity Oracles for the Enterprise' that are needed until we reach the truly internet-wide meta-system).

I fell into the trap of calling that technology component an Identity Oracle (hey, I work for Oracle, you can understand the attraction). After reading your post, I agree that for useful dialogue, it is necessary to avoid the terminology issues so common in the IAM space. Johannes Ernst even took a humorous shot at the name when I presented this concept at DIDW. So I am now in need of a name for this component that I have been working to define. Check out this blog post (http://blogs.oracle.com/talkingidentity/2007/10/10#a191) in which I talk about the technology component, and let me know your thoughts.

[Curious reader]

How does the "Identity Oracle" model differ from the "Infomediary" model that Hagel and Singer extensively advocated in the late nineties in, among others, their book "Net Worth"?

[Ron Williams]

It should not be lost on the reader that the mechanism you've described is a policy decision engine. Given (x, y, z, ...): Y/N/Don't know.

It does raise the question of inference. What safeguards would a system require against multiple and/or ad hoc queries from which specific data about a subject might be inferred?

I won't argue that its still an access control problem though fundamentally I think it is. The real challenge with privacy (and user-centric identity management) is to me the intractability of controlling remote data a la DRM, and that's why its mitigation is social/legal issue. But that's a different topic.