Arbitrage

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.

The Limits of Self Assertion

One of the commonly voiced dissatisfactions with SAML and Liberty is their implicit reliance on a third party to make assertions on behalf of a user. The idea of a corporate identity provider dishing out personal information raises privacy and civil rights concerns and as a response to these concerns, many personal digital identity systems have evolved which allow the user to manage and selectively assert identity attributes on their own (e.g LID, i-names, etc.).  While self-assertion is useful, it is only appropriate within a very specific sphere  of identity transactions, it cannot be the sole basis of federated identity. Many identity transactions require a level of trust that can only be achieved through the use of a third party. 

An example from the physical world helps illustrate the limits of self-assertion and the neccessity for 3rd party identity assertions.  Your age is an identity attribute which you can assert in any number of contexts. On a first date, at a cocktail party,  or in any number of social settings, self assertion is the best way for this attribute to be conveyed.  In these settings a person retains complete control over who they tell their age to and what age they claim to be and that's great, but there are distinct limits to the types of transactions where self assertion works. For example, when I buy a movie ticket and ask for a senior discount or when I buy a bottle of Ketel One, self assertion of my age is not sufficient.  In those settings, I need to present my driver's license on which the state (acting as a trusted 3rd party) asserts my age on my behalf. The movie theater owner and the liquor vendor both require a 3rd party in order to trust and verify my age, as they should.

There is currently no virtual analogy to a driver's license - but it is a safe bet that trusted 3rd parties will play a key role in digital identity on the Internet - there are just too many transactions where self assertion falls short. For this reason, it is important to place digital  identity discussions in a personal or enterprise context - this is where  the airplane/bicycle framework posted by Stefan Brands is particularly useful.

In an ideal future - the land of the universal metasystem for identity - personal digital identity systems will somehow interoperate with more trusted federated identity systems.  Until then, it is important to have a very clear and distinct understanding of the differences between these two ways of thinking about and implementing digital identity technology.

Planes, Trains, and Bicycles

Stefan Brands has created a fun way of  distinguishing personal digital identity systems from enterprise federated identity systems - he uses a transportation analogy and classifies personal digital identity systems such as FOAF and LID as bicycles whereas SAML and Liberty are jet planes. 

Under this taxonomy, I see LID as a unicycle - novel, but impractical and limited to people with a very specialized set of skills. As has been dissected  in numerous other places (most expertly at Burningbird), LID's dependence on URLs as an identifier misses the mark in a number of ways - like a unicycle, LID is just not a useful way to get around.

 

SXIP would then be a Cessna - complex enough (with its hosted identities and 3rd party assertions) that you need a pilots license to use it,  but not rigorous enough for a broad set of air travel requirements (e.g. SXIP is not based on standards).

SAML and Liberty as they have currently been implemented might be considered the space shuttles of identity.

The net/net of extending Stefan's  metaphor this  far....the status quo is inadequate and ripe for innovation on a number of fronts.

Dear ACLU, Let's Talk.

The Pizza flash animation developed by the ACLU is making the rounds as an example of the worst digital identity nightmare imaginable. In my circles - mainly digital identity technologists and vendors - the scenario gets a wide variety of reactions ranging from incredulity, to fear, to admiration/jealousy - in the sense that the animation demos a level of interoperability much sought after, but never approached, in current implementations. What is not up for debate is that the ACLU, in its role as the most prominent guardian and amplifier of privacy concerns, is a key stakeholder in the evolution of digital identity on the Internet.

Jon Udell sees ACLU Pizza as a sign that the digital identity community needs to improve its communication skills:

The would-be architects of our digital identity future will also have to communicate their understanding in compelling ways.

He is right of course, but I also read ACLU Pizza as a call for conversation. The ID Heads and Privacy Wonks need to sit together around the same table and inform each other.

As a trial balloon, I have emailed the ACLU contacts listed on the animation in a grassroots attempt to kick start a meaningful exchange of expertise and concerns between the ACLU and the technical community developing digital identity systems - primarily by inviting them to attend Digital ID World in May in San Francisco. Stay tuned, I will blog any developments in this effort to create dialogue.

If they do chose to attend DIDW, I imagine that members of the ACLU would be surprised to learn that privacy is a paramount concern to many of the leading innovators in the digital identity space and that it is widely believed in our community that one of the most likely outcomes of advances in digital identity technology - particularly advances in identity portability - will be the empowerment of individuals.

For example, take the dashboard demoed in the Pizza flash, take it away from the Pizza place, and put it in the hands of the person ordering the pizza. This guy now has easy access to all of the relevant data (medical, culinary, financial) that should inform his pizza order - and he would still have the option of ignoring that info and ordering double meat! (with a single click to place the order, do the billing, and provide driving directions to the delivery driver...)

It is that space age level of automation, convenience, information access, data integrity and security that the digital identity community is working towards - but the technology does not have to deliver those benefits at the expense of privacy and personal choice. On the contrary, advances in digital identity technology hold great promise for improving privacy protections and empowering individuals - but to design systems that best address privacy concerns, we in the digital identity community need to sit down with all the key stakeholders and talk it out.

SAML 2.0

Paul Madsen of Entrust provides an excellent flyover for SAML 2.0 at XML.com. Here's the link (courtesy of Bryan Field-Elliott). Note the convergence between Liberty and SAML...