Talking Identity

It took me a while to recover from last weeks Digital ID World conference. And it wasn't just because of the mad scramble I went through at the last minute to update all my slides for my talk. That was just the side effect of spending too much time in some really interesting sessions and fascinating conversations at this year's conference.

I mentioned in my last post that the theme to emerge from the first three keynotes was that the nature of identity is about to change. The rest of the conference was a continued emphasis on this idea, and on the topic of identity as a service. And the sessions drawing big crowds were the ones that talked more about emerging identity technologies and architectures.

What of OpenID?
The session 'Understanding OpenID and the Early Implementations' by David Recordon (SixApart) and Eve Maler (Sun) drew a pretty big crowd. Interest in understanding the value of OpenID was high (something the OpenID crowd has not been able to articulate clearly beyond the simple positioning as "SSO for the Web", leading to some interesting discussions by Bob Blakely, Stefan Brands and David Recordon). Folks were especially interested to hear what Eve had to say, in light of the effort Sun made to issue all employees an OpenID. To be honest, it was a little disappointing. If I remember correctly, she said that uptake has been low. This could partly be because Sun did not create any value for the Sun issued OpenIDs by incorporating it into the work life of a Sun employee. None of Sun's community sites (like those for open source projects) accept these OpenID's for authentication, and it cannot be used at Sun partners or service providers either. In fact, it seems like it is mostly a curiosity, evident when she pointed out that the highest usage of these OpenIDs seems to be at a British gambling website. Oh well, it is still early, and hopefully some of the debate in the community will get us further along.

Microsoft makes a Services play
The talk 'SOA and Identity with BizTalk Services' turned out to be a disappointing follow-up to Kim Cameron's keynote. What I took away from the session was that Microsoft is taking the features they have in BizTalk Server, and rolling out hosted services on top of that. Maybe I am wrong and there is more to it. But with the demoware breaking a couple of times, poor Justin Smith had to resort to a couple of "I think you get the picture" statements to make whatever point he was trying to make.

British Columbia presents the Next Identity Architecture
Ian Bailey, Director of Application Architecture for the Province of British Columbia, gave a very interesting presentation on their undertaking to design an identity management architecture that will deliver what they call "Citizen-Centric Identity Services". The solution he presented in his talk 'A Claims Based Architecture for British Columbia', was quite interesting to hear. The content of the session has evolved from the presentation he gave previously at another conference, and included much more detail with regards to the identity services needed to make it practical. Their architecture document can be found here and makes for very interesting reading. His session was quite inspiring to me actually, as it gave me an answer (not necessarily the answer) for one of the areas of my presentation that I was having the most trouble with.

Identity Services
That part was the discussion of the API layer needed in any identity services framework. As I pointed out in my talk on 'Externalizing Identity' (you can download the presentation here), the primary purpose of creating identity services is to make it available to application developers so that they can make identity a part of their business logic without having to build the necessary infrastructure. And the API they must code against must be simple enough to use easily, and abstract enough that it has no dependency on the underlying service providing product. Developers cannot code to XML-based standards, and so the idea of a claims-based API seems brilliant in its simplicity. Not sure if it is do-able just yet, but it is worth looking into.

Those familiar with my previous talks and blog posts about identity as a service will note that my architecture for the identity services layer has evolved over time, and has changed quite a bit even from my talk at the Jericho Forum not even a month ago. One of the key changes was the transformation of the "Identity Provider" service into an "Identity Oracle" service. It took a while, but I was finally able to articulate in detail the necessary features of this service that justify renaming it to the term that Bob Blakely (of Burton) introduced at last years Catalyst (or was it 2 years ago?). The feedback I got on the idea of a productized Identity Oracle, and the session in general, was quite interesting and encouraging. So send me your thoughts as well.

For those that are interested, I know that the DIDW folks recorded the audio of the session. I'll try and make that available here if allowed. If you went to DIDW, you can access it from the post-conference website.

Yesterday I read an article in the New York Times entitled 'Securing Very Important Data: Your Own'. One of the rare mainstream discussions about personal identity management (as opposed to the common identity theft related articles that you see constantly), the article touched upon some of the more interesting discussions that are going on in the IdM community. Most of these are in the second half of the article, after you get past descriptions of yet more online services that want to know more about you and hold onto and use that data. It is an extremely good article, so give it a read.

In the article, Denise Caruso quotes Drummond Reed to explain the core value of identity services:

"The myth is that companies have to know all this information about you
in order to do business with you. But from a liability perspective, the less I
know about my customers the better."

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

Seems like all of a sudden the New York Times is a font of knowledge about identity management topics.

In an interview that he gave to Saul Hansell for the BITS blog of the NYT, Dan Nye, the chief executive of LinkedIn, said the following about the emerging idea of a social graph for the web:

"When people tell the story that there will be one graph they are crazy," he said. "These are different platforms that are built for different purposes, with different members and different relationships between them."

• Brad Fitzpatrick & David recordon on "The Social Graph and Social Network portability"
• Microformats Wiki
• Phil Hunt on "Social Graph Search & Social Network Portability"

Last week I commented on Dan Nye's apparent lack of understanding about the need for a social graph for the web. This week, I read the following comment by Mark Zuckerberg, founder and chief executive of Facebook, on how he defines the social graph:

"When we talk about the social graph we are talking about the set of connections, friendships, business connections, acquaintances, that everyone has in the world... We are trying to take the social graph that exists in the world and try to map it out... We have a model of social graph that we are constructing."

This is an interesting time for me at Oracle. One of the reasons why I haven't been active on this blog for a while is that I have been immersed in discussions about fusion architecture and how identity services fits into it. Those following my blog know that one of the initiatives I have been involved in is the definition of Fusion Identity Management, a layer in the architecture of Fusion applications that provides identity management services for the overall deployment. Last week I was at Oracle HQ participating in a series of meetings on the viability of identity services in fusion architecture. The question is not whether identity services is part of fusion architecture (it is, of course), but rather what form it will take.

Any question about the viability of identity services is tightly tied to the viability of SOA in how enterprise applications are built, something which is being strongly questioned in the industry (the sheer number of articles, blog posts and analyst reports with the words "SOA", "myth" and "reality" in the title is an indicator of that). The big issue in any SOA debate tends to boil down to performance and availability concerns.

Also muddying the waters in the fusion discussion is the blurry boundary between identity data and HR data. HR is universally acknowledged as an authoritative source of identity information in an enterprise context. However, it becomes problematic when we have to divide up the data that HR masters into identity data that applications come to the identity service to access and HR data that applications (which by definition would then be tied to HR) go directly to HR to access.

One of the reasons why Fusion Identity Management is more than just the typical identity services discussion is that the nature of Fusion Applications is much more complex than the typical application that we consider when we talk about identity services. In Fusion architecture, we are talking about managing identities in thousands of applications across a few application pillars, with some pretty complex interplay among them. Externalizing identities and roles becomes a lot more complex (and at the same time a lot more important) when security is being integrated into every tier of such a complex mega-application architecture, be it UI, business logic, middleware or database. And when I heard about the need to support disconnected mobile applications with no connection to that identity cloud in the sky, I found myself reaching for the Tylenol.

All this means that those of us working on identity services have some pretty tough questions to answer.