OpenID, Successful Failures And New Federated Identity Options

If you're a security and risk professional in charge of protecting consumer-facing applications, you may have heard that OpenID is a “toy,” or it's an insecure protocol, or other critiques. And then here comes the recent news by former early adopter 37signals to drop its OpenID login support, which has occasioned some soul-searching in the Web 2.0 identity community. Check out commentary from Scott Gilbertson of Wired's WebMonkey, Dare Obasanjo, and reaction from “social login” vendor JanRain

When OpenID appeared on the scene, more robust solutions based on SAML were well under way for many years and seeing adoption, but only in scenarios involving limited circles of trust — typically point-to-point enterprise outsourcing scenarios and specialized higher-education communities — rather than in broad-based consumer populations. 

The reality was, despite a lot of talking, a lot of trying, and a lot of hoping in the formal identity standards community, consumer identity providers didn't really exist yet; OpenID opened the door to them and gave “button-based login” — which allows users to click on a button that identifies their preferred identity service for logging in at a third-party site — its start. And the “good parts” of OpenID are continuing to influence the development of new solutions and best practices for succeeding with federated login.

So I agree with Gilbertson's fairly nuanced take, which teases apart OpenID's original geeky goals from its value proposition today (for example, identifying the U.S. Federal government's support of OpenID as an important marker and noting OpenID Connect as an important way forward) and assesses it positively but not indulgently — “The legacy of OpenID may well be that it was ahead of its time, but that hardly makes it a failure.”

And really, “Whither OpenID?” isn't quite the right question to ask. Facebook — along with Twitter and LinkedIn and more — has demonstrated that, when it comes to lightweight consumer-scale federated identity, the specific protocol matters less for success than the user base, the nature of the data available about those users, and the tooling available for relying-party integration. (Do you suppose that if Facebook had chosen, say, SAML instead of OAuth for the latest incarnation of its authentication and authorization layer, third-party apps wouldn't have rushed in and hooked up to that sweet, sweet source?) And other factors and constraints come into play depending on the sort of business you're in.

The lesson, not surprisingly, is to consider the totality of your business goals and constraints in assessing the risks and benefits of becoming a relying party to the big consumer identity providers. I'll be researching this in the coming months and welcome your thoughts along the way.

As food for thought, I thought I'd share a nascent Venn diagram comparing the features of key technology approaches that may be competing for your attention in propagating and consuming identities successfully and securely beyond the enterprise.

Comments

Google's Internet Identity Research

I think that the work that Eric Sachs and his team have done should be considered, too. There is a big difference between supporting OpenID on Google and on 37signals - mainly, number of users. I have been following all the posts that you reference. Then I go back and read the material on Eric's site, and I hear the Sesame Street Martians in the background going "oooOOOOO" and "Yep! Yep! Yep!". I think Google has a pretty low talk/do ratio here and deserve some cred.

What OpenID means for federated identity

The OpenID post mortems are interesting. And they're important because OpenID was the poster boy for federated identity. It is one of only two current technologies (the other being InfoCards) explicitly mentioned in the OIX Framework, which forms the basis for NSTIC.

I don't think the OpenID analyses so far get to the nub of the problem. If we read some of the text carefully, we can see why.
- Janrain's blogger remarked that in future "users will expect to be able to use an account that they already have to access ANY website" (capitals added)
- Scott Gilbertson said OpenID PROMISED "an easy way to log in to ANY website without needing to create a new account" (capitals added).

These promises are not for IdPs or identity schemes like OpenID, OIX or NSTIC to make. The devil is in the details. With their choice of words, federated identity proponents systemically exagerate -- unconsciously or otherwise -- the potential of their systems. For instance, under NSTIC it has been said by no less an authority than the Whitehouse that "a student could get a digital credential from her cell phone provider and another one from her university and use either of them to log-in to her bank". The changes needed to risk management arrangements, contracts and laws for universities, phone companies and banks to make this happen are truly radical.

The unresolved business and legal challenges implicit in federated identity are to blame for the under-delivery of OpenID. We need to more thoroughly understand these issues if the OpenID experience is to be avoided by much more important programs.

Re Google and trust frameworks

Hi Sid and Stephen-- Thanks very much for your comments.

Sid, I agree; Google has done a great job on UX and account linking best practices, and of course its user base has some attractive features similar to those of Facebook. (Nice Sesame Street reference! I love those guys.)

Stephen, you're hitting on a really important point. A classic federated identity triangle has users, identity providers, and relying parties. Hopes and wishes for broad-based identity ecosystems are typically expressed as promises, but of course no one can speak for all the parties, and wishes do not a thriving ecosystem make. The sticking points, especially as the demand increases for higher-value identity data and deeper privacy assurances, are going to be more legal and operational than technical, so the new work on trust frameworks is key.

OpenID for login

We are implementing OpenID as an option for identification because it really is easier for users. A person who is always logged on to google or facebook does not want to have to logon every time they come back to an occasionally used site.

We know that if someone uses their google email address as their user id then there is a high probability they will use their google password with us and we do not want the responsibility of looking after google passwords. If Google will look after their own passwords but allow us the functionality then that is a pretty good deal. We will not implement a completely open openid but we will use the common sources and with those companies whose implementation allow for a good user experience.

What is good about OpenID is that the large identity providers - for their own protection of their own passwords - are allowing us to use their usercode passwords and because they have used OpenID the technical details are much the same for each source.

We expect the same thing will happen with other data that people want to use in different places. That is, each of us really only want one master copy of important data in one place but we want access to it from many places. With standards users can have important data in one place but they can move it easily, if they wish, to another place. Hopefully in the future they will be able to remove all references to it just as easily.

The OpenID proposition for relying parties

Hi Kevin-- Thanks very much for sharing your business drivers for becoming a relying party. Your mention of avoiding a data protection burden ("the responsibility of looking after google passwords") in outsourcing authentication is interesting. And I agree that the possibilities for authorized sourcing of user data from a variety of Web-friendly attribute authorities are tantalizing!

Evolving identity

First off, loved your venn diagram it very graphically called the shots.

I like to think of the changes happening in the IDM world as just natural selection acting on the technologies. It pushes the development community in the right direction - towards highly usable and accessible identities. The word 'identity' I think may be the crux of the problem. To me, OpenID has never really been an identity - it's really a credential that could be part of an identity. Maybe we expect too much of a simple credential, after all, we don't expect our Facebook Connect account to do anything other than log us into facebook (or another account).

I perfer to think of login methods like OpenID, Facebook, Twitter and GoogleID, etc. as credentials that we own, that we can use with a digital identity, i.e. something that can transact lots of identifying information about us. Now I suppose it can be argued that facebook could potentially join up the dots and link its connect credential with that information, but then there's arguments about the validity of said info. I have my own thoughts on this and a way forward.

Going back to your Venn diagram, I cant say who with, but we are working on solutions that fit into the intersections of your diagram - as long as you allow for natural selection in your company development strategy, I reckon you can get to that holy grail of verifiable identities with SSO and accessiblility and consumer scope and usabililty...

Credentials vs. identities

Susan, thanks for writing. I really like your distinction between credentials and identity, which neatly encapsulates something that has occupied many hours of discussion in certain communities over the years. :-) (Maybe holding the discussions "over beers" has been the problem!) My belief is that you're exactly right about the various features being merged, as dictated by opportunities and pressures. Sometimes I think an "identity singularity" is approaching -- if we are careful in respecting various and sometimes countervailing needs for security, assurance, privacy...

Identities are relative

I caution that the difference between identity and credential is arbitrary. One person's "credential" is another's "identity". The Laws of Identity teach this too: we each have a plurality of identities, each meaningful in a different context.

So for example, my gas bill functions as a perfectly good identity in the context of my gas company (well strictly speaking, it's the account number at the top of the bill that is my gas identity). When I call the gas company and quote my account number, that's how they know me. Sure, I have to tell them some other shared pseudo-secrets like my address and date of birth for confirmation, but my *identity* to the gas company is the account number.

Outside the gas company context, we wouldn't regard this "identity" as especially meaningful, and so a more clinical term like "credential" might feel better. But there are other more serious credentials that we are quite comfortable thinking of as "identities". A doctor's professional credentials for instance establishes their identity for the purposes of a wide range of sanctioned transactions (signing prescriptions, hospital discharge summaries, pathology orders, medical insurance claims, birth certificates etc etc).

So I think it's vital that we treat identity as *relative*. What really matters is that within each community of interest (like a company and its staff, or a medical system and its doctors, or a bank and its customers, or a credit card scheme and its cardholders, or a gas company and its clients) there is an internally meaningful and rigorous way of knowing the subjects, registering them, and setting rules for they are allowed to do in that community. The identities we have in each CoI are really proxies for the different relationships we have in each context. The terms and conditions for exercising one's various identities/credentials have evolved over time to suit the needs of different niches in real world business ecosystems.

It doesn't matter whether we call them identities or credentials; what's important is that they stand for complex relationships that determine how we transact in different contexts. On a case-by-case basis, before we can attempt to federate these relationships across different contexts, it is imperative that we first appreciate the subtleties of how they have evolved.

True Identity

Stephen, I do understand the point you are trying to make but I must disagree with it from both a philosophical/anthropological standpoint as well as a technology one.

Our foray into the world of digital identity will arguably be much more successful in the long term if we use the rules governing the evolution of our 'real world' identity: This is a highly complex matrix of behaviours and indicators (such as facial features). Now currently we don't have the know how to truly mimic these things in the virtual world but I'm sure one day that will be possible, perhaps using algorithms based on fuzzy logic analysis of behavior.

This then means that the technology expressing what is truly an identity, should be able to convey or 'transact' that information in as closely fluid and real time a manner as we do when we convey our real world identity. This creates a very powerful platform for all sorts of tasks that need to be performed online, from access control, to policy enforcement to digital signing.

A credential does not have the technological means to act like an identity because it's scope is limited by its underlying protocols and lack of scope in terms of managing and expressing those identifying features (ideally in real time) that make up something that can truly be called, an identity. In fact, a credential can be part of an identity, as an identifying factor within the identity matrix or as a means if authenticating the use of the identity, as something the owner knows.

Compartmentalisation

But Susan, it's actually exceedingly rare for us to "convey our real world identity" when we transact in routine business. I don't tell a store who I "truly" am. I use a nickname in OSNs. And I don't know who my doctor "truly" is (and hence my contention developed elsewhere that authorization is often more important than, and separable from, authentication).

We compartmentalise our different digital identities. There is no shortage of synomyms that avoid the connotation of singularity in the word "identity": guises, personae, etc. But whatever we call them, we do create succinct independent proxies by which we are known in different contexts. Don't we need to keep the singular "true" identity well away from cyber space as much as possible?

Minimal disclosure

Well that's why minimal disclosure, or just confirmation claims, were invented.

However, even in the real world we often have to give out information about ourselves. As long as the technology is privacy aware then I don't see any issue with a rich array of identifying attributes being fostered.

An analogy with money

I am involved in a discussion on the "meaning of money" and there is a correspondence with the ideas on the "meaning of identity tokens".

People fall into the trap of thinking of money as wealth whereas money is a "pointer" to something of value.

Similarly when we start to think of an OpenID or any other symbol as being an identity we get into difficulties. It is really a "pointer" to an identity. It is not an identity.

This is the same with all our symbols. As long as we recognise them for what they are - tokens that represent something else - then we will cut short a lot of long beer soaked discussions. (which may be bad thing:).

The safest way to de-identify ...

... is to not identity in the first place.

[which is a paraphrase one of my fave philosophical tidbits: The fastest way to get somewhere is to be there already!]

I agree of course with minimal disclosure, but the way it manifests in the Identity Metasystem is too often overly complicated. To achieve "verified anonymity" for example, you are supposed to register with an IdP or Attribute Provider, divulging all sorts of personal information as part of the sign up process, and then the service can represent you anonymously to an RP by holding back all attributes except the pertinent one.

A subtly different approach is to create a certificate in advance, matched to a transaction context (such as 'accessing adult services') that contains nothing more than an anticipated assertion relevant to that context ('the subject is over 18') plus a specification of its intended context. For accessing your health records you have a different certificate asserting your health ID. For shopping you have another certificate asserting your credit card number. In my simplified view of the world, for most transactions, the RP is the IdP, which means that such certificates can be issued in each context based on existing relationships, and without the subject having to disclose any extra PI at all. This avoids creating new IdPs, or re-casting existing IdPs into new expanded roles, both of which are problematic for privacy, and are a helluva price to pay for 'minimal disclosure'. And it avoids creating novel three-way legal arrangements between S, RP and IdP to replace the mature S-RP bilateral contracts already in place.