Julie Zhou of Facebook discusses usability findings from Facebook Connect. Photo © John McCrea. All rights reserved.Monday last week marked the first ever OpenID UX Summit at Yahoo! in Sunnyvale with over 40 in attendance. Representatives came from MySpace, Facebook, Google, Yahoo!, Vidoop, Janrain, Six Apart, AOL, Chimp, Magnolia, Microsoft, Plaxo, Netmesh, Internet 2 and Liberty Alliance to debate and discuss how best to make implementations of the protocol easier to use and more familiar. John McCrea covered the significance of the summit on TechCrunchIT (and recognized Facebook's welcomed participation) and has a good overall summary on his blog. While the summit was a long-overdue step towards addressing the clear usability issues directly inhibiting the spread of OpenID, there are four additional areas that I think need more attention. I'll address each separately.

Make it easier!

Overwhelmingly criticism of OpenID has been leveraged by developers and web users alike against OpenID's ease of use. For developers, implementing OpenID is confusing and cumbersome, and often tacked on as an afterthought to appease annoying early adopters (like me) who badger them to support the protocol. Even those who support the protocol report little upside, compared with something like Facebook Connect, which brings with it richer aspects of someone's profile and social graph. For web users, OpenID is confusing and frustrating, resulting in what I call "OpenID double registration taxation" — where a user, immediately following OpenID authentication, is prompted by the relying party (RP) to supply, and then verify, their email address. Why bother with OpenID if they're going to have to go through the old school registration process anyway? Where's the benefit in that? On this latter point, we probably won't make much headway until email harvesting goes out of vogue, which won't happen until there's a better way for sites to spam/bacn their members (bacn: "email you want, just not right now"), or until OpenID Providers (OPs) more consistently pass on profile attributes via SREG, Attribute Exchange or PoCo (or until people realize that email is dead to the MySpace generation). Unfortunately, mandating that providers pass on profile data is something that cannot, and probably should not, be mandated by the OpenID spec, even though in comparison, Facebook Connect always provides some data. Fortunately OPs like Yahoo! are starting to improve this situation, by enabling opt-in controls that enable users to share their data more easily. If this trend continues, we may see fewer "double taxation registrations" and smoother OpenID login flows. Still, for both end users and developers, OpenID must become easier to use and more obvious to implement. Fortunately, there is now fairly widespread recognition within the OpenID community of specific issues and a strong willingness to address them. To that end, for example, advocacy for email addresses to be used as OpenIDs is growing, providing web users the convenience of reusing a familiar identifier, and affording developers a way to "upgrade" legacy userbases that may have been keyed to unique email addresses. It is my opinion that enabling an email address to be used as a "hint" that resolves to a valid OpenID URL is a necessary step to dislodge one of the main nettles against OpenID. I also believe that this step is necessary to bridge the impending generation gap that's sure to develop when MySpace flips the switch on their OpenID provider, enabling over a hundred million URL-based OpenIDs. Privacy concerns notwithstanding (remember, most RPs already demand a verified email address anyway), there are few reasons not to use email addresses for OpenID. I'd rather just make it so and let people pick for themselves how they feel most comfortable identifying themselves on services and move on to meatier issues.

Branding and marketing

On that note, Max Engel from MySpace brought up some important points about what it would mean to enable email addresses as OpenIDs. Soon to be one of the largest providers of URL-based OpenIDs (i.e. myspace.com/factoryjoe), he's concerned that people will only implement support for email addresses if the OpenID spec provides a way to translate email addresses into URLs. This is a valid concern, but one that can be mitigated both in the language of the spec, and in the libraries that perform OpenID authentication. Here is where I see an opportunity to finally establish OpenID as a brand unto itself, where the word "OpenID" can and should come to mean something to people (though of course not without an ongoing substantial and sustained marketing effort, lead by the OIDF, but primarily prosecuted through grassroots and community "spreading vectors"). Here's why: people have learned, over time, that "email" is easier to say (and shorter to type) than "electronic mail". When you ask someone for their "email address", most people on the web can give you the answer you're looking for. We're a long way off from the same kind of familiarity with OpenID, but ultimately you have to start somewhere. And because "URL-based identifier", "blog address", "profile link", "home site" — ad infinitum — probably don't mean much to anyone (let alone the same thing) there's an opportunity to converge on a term that's easy to say and captures the concept fairly well (or well enough) and is otherwise not known. It's also important to consider that not all URLs are in fact OpenID-enabled. This point alone is enough to convince me of the importance of the OpenID name and the potential for the brand. When you ask someone to sign in to your site, you can be pretty sure they'll know what their email address is. If you ask them for a URL, and they provide you with a perfectly valid address but one that is not OpenID-enabled, they will not be able to sign in. If we can make it clear that "having an OpenID" is something special, and that not all URLs are OpenIDs, then we can begin to create the kind of awareness necessarily to confidently ask people for an OpenID, and have them respond appropriately. It is here that I disagree with Scott Kveton, who has long argued that his mom didn't "get SMTP, they got email". I appreciate his sentiment and used to agree with his argument in principle, but now that I've thought about the fact that only "special URLs" are OpenIDs, I think it's worthwhile to give that class of URLs a specific name.

Consistency

Furthermore, one of the greatest threats to the viability of OpenID is an inconsistent user experience. Unfortunately, this manifests itself both when signing in to a malfunctioning relying party, or attempting OpenID authentication using an OP that an RP doesn't support (e.g. Microsoft Health Vault currently supports three OPs). Another manifestation of this problem is that OPs are not required to consume OpenIDs. Though there's validity in this complaint, change should not be forced at the technical level, because it really should be up to each individual provider to determine whose credentials it's willing to accept. Now that the majors (save Facebook) have all gotten into the OP game (most recently Microsoft), it really just seems a matter of politics and inertia that none have moved to accept the OpenIDs of their competitors in any significant way (that is, neither Yahoo, Google, or Microsoft allow authenticating against their respective services using one of the other's OpenIDs — and no, Blogger doesn't count and Google hasn't really released their OP yet). While I'm sympathetic to Allen Tom's argument that more OPs is frankly better for the web, I'm not convinced that a Visa card is all that useful if none of the major department stores will accept it. I certainly respect large providers' desires to both minimize the potential for abuse and to wade through the legal morass around identity technologies, but I can't see how becoming an OpenID relying party is any worse than letting people create accounts with arbitrary (and untrusted) email addresses. Hopefully through both political pressure and success-in-the-wild over time, we will see the majors become relying parties to their competitors' OpenIDs for accessing accounts, and over a longer period of time, enable the use of personal/private OpenID providers or delegated OpenIDs (e.g. factoryjoe.com). Should we see this situation change, I think it'll bring about a watershed migration to patterns established by the majors — leading to consistency in the OpenID sign up and sign in experiences, and consistency in what people expect of OpenID account federation, leading to increased credibility and use of OpenID generally.

Leadership

But let's get real: all these issues are going to require, above all else, solid foresight and leadership and a commitment to pushing through the thorny political issues that can often scuttle the best intentioned technologies (consider HD-DVD and Blu-Ray). For reasons beyond my grasp, the OpenID Foundation has not met up to my expectations of leadership. Despite considerable progress in some areas, large swathes of stagnation have come to subsume many of the organization's initiatives. International progress, as overseen by the OIDF, is lacking, except where local chapters (such as in Japan and in some European cities) have taken matters into their own hands. Code improvements to the OpenID libraries has languished and implementation of OpenID in various platforms and open source projects seems non-existent. Marketing simply isn't happening and even if it were, I'm not convinced that there's consensus on what we should market. And only now, after research from Yahoo and Google confirm what many critics have said for a long time is there finally work being done to address OpenID's usability pitfalls. Now, I realize that technologists don't always make the best politicians (or designers or marketers for that matter) but that we haven't seen the kind of OpenID visibility, credibility, innovation and adoption in North America that has been seen in Japan suggests to me that we're either on the wrong course, or no apparent course at all. Worse, I fear that certain companies are already dividing up the proverbial "identity pie" before the damn thing's even been put into the oven — a situation that needs to be addressed immediately by prioritizing a series of steps that the OIDF will take to establish OpenID in the marketplace, set firm how it will support individuals and companies alike, plot out its administrative and advocacy agenda for 2009, make clear its budgetary outlook, and list the marketing, design, education and research initiatives it plans for the coming year. Without a clear path forward, I think that a lot of otherwise positive energy will devolve into useless sniping and infighting. Without strong leadership, we risk marginalizing many of the gains we've made to date in establishing OpenID as a core building block of the open social web. For comparison, consider the progress that has been made with OpenSocial: only a year ago, people dismissed it as a "Gadgets API" (which, arguably it was). Since then, a large coalition of the willing has gathered to support and develop the protocol (which is still far from perfect, but demonstrates steady progress towards a goal), even convincing that old salt David Recordon that what they're doing is decent. When OpenSocial 1.0 is released (they're at 0.8.1 right now), there will be a distributed social graph with over 350 million potential customers available to developers (compared with around 100 million on Facebook). While David is right to point out, with Microsoft coming on board, there'll be well beyond half a billion OpenIDs in the wild, that doesn't mean that our work is finished. Rather, it's just begun, and David sums up our situation fairly well:

While this is great news from Microsoft, real web-scale adoption of technologies always faces a chicken-and-egg problem between developers and vendors. Developers don't want to adopt a technology without buy-in from platform providers and platform providers don't want to support a technology if developers won't use it. We've largely been able to successfully avoid this concern with OpenID as it grew from roots in an open source community with lots of people and companies involved in making OpenID what it is today. There are now well beyond half a billion OpenIDs available on the web which means we can mark the first phase of OpenID adoption, platform support, as a success. The next phase of developer adoption will not be measured in the number of OpenIDs or sites that support it, but rather user experience, accessibility, and seamlessness of integration into a wide variety of applications and experiences.

To that end, there will be an Internet Identity Workshop in Mountain View November 11-12 where many of the primary participants in the ongoing identity conversations will converge. Historically the event has been one of the most productive in the space and with all the recent OpenID news lately, I'm hopeful that many of the issues I've mentioned above will be addressed and progress will continue to be made. I will continue to be a staunch advocate of OpenID and think that it's best times are still to come, but not without a redoubling of focused effort around concrete and ambitious goals.