Written by guest writer Dirk Balfanz. Dirk is a software engineer at Google (although expressing his personal views here), where he is working on Internet Identity and Data Portability-related projects. Prior to joining Google, Dirk worked and published in the area of Usable Security.
OpenID has been around for a while, but has for most of its life been a niche technology. This is not too surprising since it was originally designed for authenticating bloggers wanting to comment on other bloggers’ blogs.
More recently, it has been embraced by some big players like MySpace, Yahoo, Google, and Facebook. Even before it was picked up by the industry heavy-weights, the OpenID community revved the version to 2.0, anticipating some of the use cases beyond blogs. For example, users were no longer required to know their OpenID URL, and enter it at the Relying Party’s (RP) web site. Instead, they could just tell the RP who their OpenID Provider (OP) was, and log into the RP that way.
Still, OpenID 2.0 is in some ways inadequate for today’s requirements.
For example, many enterprises want to become OpenID providers or relying parties, but don’t want to run, and maintain, complex servers implementing OP or RP functionality. Rather, they would like to push that functionality into the cloud, and leave it up to Software-as-a-Service (SaaS) vendors to provide that capability for them.
Another example is the problem of user experience: A web site typically cannot rely on OpenID as its sole means of user authentication. Providing the user with a range of options – from setting up accounts on the site directly, to logging in using popular OPs, to allowing arbitrary OpenIDs, to also supporting non-OpenID federation solutions like Facebook Connect, or Sign in with Twitter – can quickly lead to a daunting login page that can scare away even the most willing users.
Over the next few weeks, I’ll be posting a number of articles here that deal with OpenID. I’ll cover a few technical topics that I believe a new version of OpenID will have to address, and where possible outline solutions. In particular, I think I’ll be talking about the following:
- Users vs. Identity Providers: Provider-Discovery vs. User-Discovery: This article will explain the difference between user discovery and provider discovery, and is required reading for the next article.
- OpenID and LRDD: This article explains how a next-generation OpenID discovery flow can sit on top of the Link-based Resource Descriptor Discovery.
- Email Addresses as OpenIDs: This is always a popular topic. I’ll explain how something like this can fall directly out of the LRDD and webfinger.
- Secure Discovery: Delegation in OpenID is currently not very secure. I’ll explain how discovery can be made more secure.
- OpenID UX: I’ll talk about different options that RPs and IdPs have for giving the user a pleasant experience.
Possibly (probably?) the list of articles will change by the time I get around to writing them all, but this is the plan as of now.
The first article in this series will be published July 27th.