Revisiting the Identity Oracle concept

Yesterday I talked about the NYT article on personal identity management, and alluded to the discussion it generated on the nature of the Identity Oracle that Burton’s Bob Blakely introduced a while ago. The Identity Oracle concept is at the heart of any L.L.P based identity infrastructure.

Kim Cameron read the article and the following blog posts about it, and equated the Identity Oracle to a Claims Transformer in his post about the article. Bob corrected everyone’s understanding on the definition of the Identity Oracle in a blog post called, bluntly enough, “What the Identity Oracle Isn’t“.

Identity Oracle as Business Service
Bob points out that the Identity Oracle is not a technology but rather a business service that other identity-based online services can subscribe to in order to get the identity data that they need. I tend to think of it as a Visa or Mastercard service for my identity data. Individuals (or anyone/anything with an online identity) can sign up for the Identity Oracle to be their agent in online transactions with identity-based services. An important part of Bob’s thesis is that the Identity Oracle’s business be restricted to this act, completely divorced from the consuming services, so that it’s core business model makes it sole guardian for the identities it is charged with, inherently making it good at protecting our data and our privacy.

I was in the middle of writing this post when I saw Dave Kearns blog an endorsement of Bob’s sentiments in his post on the topic. In it, he does allude to the need for an underlying infrastructure to deliver such a business, which is exactly what I am talking about.

Identity Oracle for SOA?
Bob makes an extremely good point in his post that we must not reduce all discussion on IdM to ones of technology. And since naming issues have always been a problem in the identity community, I am going to move swiftly to delineate the Identity Oracle business service that Bob is talking about from the technology component I introduced in my talk at DIDW (you can download the presentation from my media library).

This technology component starts as an Identity Provider, able to retrieve identity data from the multiple authoritative sources that exist for that data. But it goes well beyond this basic notion of the IdP that we are all familiar with in the federation construct. It adds the following necessary features to its capabilities:

• Support identity data stores and user-centric identity tokens as identity data sources in online environments
• Support for both definitive (date of birth) and derived (over 21, legal age, can buy alcohol) identity data
• Provide a declarative Governance Model for how identity data is made available and consumed (fits in well with the IGF concept being discussed)
  • Support for Identity Data Discovery by consuming parties (again, subject to the governance model)
  • Support for providing Usage Constraints on the Identity Data to consuming parties
  • Support for Privacy, Regulations, Compliance constraints
• Pub/Sub Models to support caching and cache invalidation of Identity Data in consuming services
• Schema Mapping from source schema to consumer schema (because lets face it, a universal identity schema will NEVER happen)
• An easy-to-use Online Service by which the identity owners (the person whose identity is being hosted, the administrator for the application that is contributing some identity information) can manage the governance, privacy and consumer rules for the identity data they have rights to manage
• A Claims-Based API for application and service integration
• Other fancy features like a translation layer

The Identity Oracle/Provider for SOA

The guiding principle for this technology component is the Principle of Least Knowledge (every identity consumer operates on a need-to-know basis). This component is an important part of the Identity Services architecture, providing the technical underpinnings of the kind of business solution that Bob is referring to. However, it is not as easy to develop as Dave and Bob seem to think (I have had way too many customers talk to me about this), and it is not restricted to the Identity Oracle use case.

The need for this technology is evident in todays discussions about how identity (as a functional component) can be incorporated into SOA models for application design. Externalizing identity from application design is a necessary first step to get to the point where services can rely on things like an Identity Oracle for their data. And as we have seen in other areas like federation, it is entirely possible that the first experiments and breakthroughs will occur in internal environments before the idea is expanded to the wider net environment.

What’s in a name? A lot (I think)
In my presentation, I had tried to distinguish this technology component from federation Identity Providers (which have their own connotation and baggage) by calling it an Identity Oracle. Now I know better :-). We all know that naming issues have caused a lot of trouble for all of us in identity management. So. if we are not to call this technology component an Identity Oracle, then what do we call it? Contextual Identity Provider? Identity Vault? Identity Brain? Identity Provider for SOA? Suggestions are welcome, so send me your comments.