A Thousand Points of Failure

CNET posted a story last week suggesting that federated identity introduces a "single point of failure" risk. This is a common objection to federated identity systems  in which the logic goes something like this: federated identity requires a single authentication gateway which provides identity into multiple services,  if/when that gateway (or a credential used to authenticate at that gateway) is compromised then all of the relying services will be compromised. It is rarely stated, but I assume one implication of this thinking is to leave the status quo in place - the status quo being unique authentication credentials and identity profiles managed locally at each service or application. 

Newsflash for readers who subscribe to this single point of failure argument...The status quo of digital identity is broken and badly in need reform!

Each and every new data (Choice)point that surfaces offers more insight into the current sad state of identity assurance on the Internet. Among other things, federated identity opens the possibility to reduce the number of Choicepoints out there - Choicepoint being this week's convenient shorthand for a vulnerable database that contains sensitive identity data - and yet the federated model inevitably leads to a discussion of a single point of failure.

Currently there are thousands (if not hundreds of thousands) of points of identity failure on the Internet. How are they administered? What are their security processes? How responsive are they to an attack? What software do they run? What recourse do you have if their incompetence results in your identity being compromised? I am fairly certain that if you started now you could answer these important questions for each and every system that stores your valuable identity assets by the end of this decade, maybe - if only you knew every location where your identity data is stored.  This is the status quo for identity – a myriad of unregulated, duplicative systems storing the key to your identity.

A Federated Future – some specifics…

So, if we can agree that the status quo needs reform, how can federated identity help improve identity assurance? In my opinion the answer lies not only in federated identity technology, but in the application architecture changes that are enabled by federated identity. For example, each of the above referenced 1000 points of failure has been built to rely on a local copy of  a complete identity profile (often including SSN, legal name, address, etc.) for every user. This highly insecure duplication of key identity assets is a result of applications being developed in a pre federation world where relying on a local database was the only viable development option for accessing identity profile information.  Systems designed to use a federated identity do not explicitly require a complete identity profile to be stored locally. An application that relies on federated identity needs only an opaque identifier that does not tie the "user" to an individual. The risk of identity theft decreases significantly if all you can walk away with is an opaque identifier and a history of transactions. 

But what if a person's authentication credential for the federation starting point is compromised? This risk is why federated identity projects often go hand in hand with the roll out of strong authentication. The pervasive use of user name/password as an authentication mechanism is one of the major weaknesses in the way identity is handled in the status quo.  In a federated future, user name and password does not exist. Users establish their identity using two factor or other forms of strong authentication and then their identity is asserted on their behalf from these strong authentication points.

What about phishing and federated identity? Phishing is a complicated problem, but I would argue that one of the reasons people are susceptible to phishing attacks is that we are so conditioned to register our personal information over and over again. The fat fingered identity assertion is commonplace in the status quo, in a federated future highly trusted systems of record will selectively register only the identity information an application needs to deliver a service. An email asking for you to manually enter profile information will seem very out of place in the federated future.

Innovation is happening in the way digital identity is handled on the Internet. This innovation is largely in response to an obvious need for reform. For the reasons listed above and others that I am not bright enough to think of, future identity systems will rely on federated identity. In other words, the federated future is inevitable.

Note to the press: this conversation has evolved past single point of failure objections to a discussion of the specific characteristics and architecture of the federated future.

Comments

[Paul Madsen]

Chris, on the potential value of federated systems against ID-theft, not only will users be surprised/alerted to see an unsolicited request for personal data, they will become conditioned to accessing their service providers only through a secure & trusted channel (which clicking on an unverified link in an email doesn't provide)

Paul