Talking Identity

In response to my previous blog post about identity services, I received the following question from Billy:

"isn't this what OpenID aims to do? If not, how not?"

Identity Services Stack

There has been a lot of discussion recently on the topic of an Identity Bus (see the recent newsletters by Dave Kearns from May 5, May 7, May 12 and May 14, and some blog posts by Kim Cameron and our own Clayton Donley). The use of the word "Bus" creates some confusion, since what is being discussed is not really related to transport of identity tokens. Instead, it is a discussion that maps perfectly to the Identity Provider layer in the Identity Services architecture I have been talking about.

In a nutshell, the Identity Provider (or "Identity Hub" to borrow another term Dave has proposed) is a service that an application can go to when it wants to retrieve identity data for any identity it cares about. This service (and its associated service provider) support some key characteristics:

• Data Virtualization: The IdP leverages virtualization technology to leave the data where it belongs - with the authoritative source of that data (HR databases, CRM databases, LDAP stores, etc) - and retrieves it as needed, combining it across the various stores to present a rationalized, unified profile to consuming applications. This means that the data is always up-to-date, and complicated synchronization connectors can be eliminated.
• Cloud Identity Providers: The IdP should not be limited to physical data stores it has a direct connection to. It must also support cloud identity providers, where the data is coming over the wire (in the form of tokens or claims) as part of the authentication or user-centric interaction.
• Simple API: This is one area where I differ with the discussion. I believe in a higher level programming abstraction that eliminates the need for application developers to become experts in LDAP, SAML or any other standards-based protocol. The API for accessing the identity data is a developer-friendly API that exposes the identity profile using a rich schema. The API layer can deal with multiple protocols underneath, thus allowing any technology supporting any protocol to act as the provider.
• Principle of Least Knowledge: The IdP enforces minimal disclosure of identity data through a combination of features and controls. This is a key characteristic that enables compliance with security and privacy needs by making identity data available to consumers on a need-to-know basis. Among the features that help enforce this are:
• Support for both definitive (date of birth) and derived (over 21) identity claims.
• A governance model that controls how identity data is provided and consumed.
• Pub/Sub Models: The IdP provides a way for consumers of the identity data to subscribe to identity data events of interest. When a qualifying event occurs (like a persons address changing or the person being promoted), then the IdP can publish an event that notifies the subscribers of the occurrence of the event.
• Schema Mapping: One of the reasons for the meta-directory not succeeding is the need it imposed on defining a universal user profile schema. This effort is doomed to fail at the very start, since coming to agreement on a universal schema is pretty much impossible. The Identity Services IdP solves this by allowing the IdP and the consuming application to each define their own schemas, and allowing these schemas to be properly mapped at deployment time. Thus an application developer can code to look for an attribute called "Surname", without having to worry about what is available in the IdP the application will eventually hook up to. The IdP can publish an attribute called "Last Name", which gets mapped to the attribute "Surname" required by the application during the deployment of the application.
  

Identity Provider