An awkward fracas has broken out in the identity standards community over the process that led to the drafting and approval of OAuth 2.0. I've participated in many standards committees myself and I agree they're difficult environments, populated with self-selected and often implacably parental technical specialists, and the processes are much complicated by corporate interests.
The arguments over committee machinations and the protocol itself concern arcane stuff that goes on under the hood of identity management. So the fuss doesn't really matter much at all ... except that as I've said before, a bigger starker problem meanwhile goes unremarked; namely, there's something amiss with the very idea of Federated Identity!
To recap ...
Framing identity management
While I wish to avoid semantic debates, it's worthwhile reminding ourselves that digital identity is a metaphor. Modern identity management theory holds that digital identity all about assertions or claims.
My digital identity as an employee is manifest as a set of claims (employee number, job role etc) that substantiate my relationship with my employer. Different sets of claims (e.g. account numbers, credit card numbers) evince my relationships with various banks, creating distinct Digital Identities meaningful in different contexts. Each of our metaphorical Digital Identities is a proxy for a different relationship we have with some service provider in a certain context.
Understanding Digital Identities in terms of relationships ought to illuminate the subtle complexity in identity federation. Re-using identities sounds simple but if we re-framed the objective in terms of re-using relationships, the challenges are more self-evident.
Unpacking the identity management problem
What problem are we trying to solve in a new overarching approach to identity management? I contend there are at least three major separable problems, which the ambitious visions of federated identity tend to bundle together:
1. "Identity theft": IDs in simple alphanumeric form (and personally identifying data in general) are vulnerable to theft and replay, because, unaided, computers cannot readily tell the difference between original data and copies.
2. Ease of Use: Authentication technologies have multiplied beyond reason and have become hard to use en masse or even individually. This is the "token necklace" problem.
3. Burden of Registration: There has been an explosion in the number of separate registrations required by online services. Many social media logons are trivial as there is no significant asset at risk in the face of misidentification. A separate issue under this heading is the mounting demand for online registration at e.g. virtual banks without in-person identity proofing.
And while it's not a problem per se, a fourth driver in many federated identity schemes is the perceived opportunity for established service providers to leverage their special knowledge of their customers into general purpose identities those customers can use elsewhere.
Beware extrapolating from social login
The low risk, low friction social media environment first spawned OpenID, and then led to social login via Facebook, Twitter and many more networks. Social login is the best and perhaps only really good example of federated identity. And it has inspired key elements of NSTIC, such as when Whitehouse security adviser Howard Schmidt blogged on the launch of NSTIC: "imagine 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, her e-mail, her social networking site, and so on".
It's an alluring user experience but the social login model is divorced from real world liability arrangements that underpin the very much more serious business of telcos, universities and banks. These sorts of identities are issued by IdPs that don't know who you are, and they're used by RPs that don't care who you are.
This is a significant gap in most federated identity work to date between the easy intuition of being able to "share identities" and the reality of taking one party's knowledge of a user in a certain context and parlaying that into other contexts and applications over which the "identity provider" has no control.
Beware of designed ecosystems
The so-called identity ecosystem of NSTIC, Kantara, the Laws of Identity and so on has not evolved naturally but rather has been designed. Artificial ecosystems tend not to be as robust as ones that evolve naturally. This is not merely an academic distinction:
A. The model embodies a number of tacit assumptions and biases that should be made explicit. For instance, there is a widespread assumption that identity silos are inherently undesirable and should be done away with. Another assumption is that the abstractly different roles of IdPs and RPs really ought to be separated in practice, with banks, telcos, universities, governments and so on all sharing one another's identities.
B. Liability arrangements and risk management mechanisms have evolved naturally over many years in real world business ecosystems where different sets of rules have come to suit different niches. The total cost (including potential legislation) of forcing changes to existing liability arrangements to suit the federated identity world view turns out to be high, and unbounded unless secondary uses of identities is carefully bounded (which erodes the federation proposition).
C. The identity ecosystem is relatively new; nobody yet knows if it is sustainable. The troubled history of conventional PKI, and the difficulty in getting many federated identity schemes off the ground, suggests that pure play IdPs are going to be hard to sustain.
What do I think should be done?
1. Carefully review the various failings in this space. There is as yet still no satisfactory unifying explanation for the surprising failures of so many worthwhile projects and products. I would like to see fresh research into the reasons any or all of the following initiatives foundered: Sxip, Microsoft's Cardspace, the Internet Industry Association (IIA) authentication hub proposal, and the Australian banking sector's Trust Centre and MAMBO projects.
2. Make incremental progress on pressing issues. For the most part, businesses and governments do a reasonably good job of identifying people in the real world and establishing their bona fides. The most acute identity problem is a technological one: digital identity data is too vulnerable to replay. Moreover this technological problem is relatively easy to fix, by automatic digital signing of routine transactions using tamper resistant keys held in easy-to-use secure portable media (like chip cards, smart phones and the like).
Your last sentence, that word "relatively"... the problem is the abstraction of administrative authority over one's prime relationship credential. The "comfort level" in relative terms is off the charts. (meaning that there are 4 groups that this confronts; 1=technically adept people who trust tech, 2=non-tech people who press 'approve' and do not care what the process means, 3=non-tech people who distrust every opaque technical process, 4=technically adept people that distrust external admin management structures)
One fix takes care of all these issues... and allows good technical solutions to be "usable" with relative ease and Individual comfort. Admin authority has to map in reverse.
The Individual requires administrative precedence over the system, every system, by default design at opt-in. Use is authenticated use when it authenticates in two directions between source authorities.
To date, we have been building IDM systems with backwards administrative precedence, and the design of administrative authority within our data systems is self-defeating us in real Human terms.
Hopefully, we can at some point explore what it is that gives any form of identity integrity and empowerment, and map it to a new root data model that civil societies can use to express themselves effectively in every context... as Individuals.