As a concept, OpenID has shown a great deal of potential. But that potential has often been hamstrung by the series of hurdles through which OpenID users have been required to jump in order to use their credentials. When Facebook Connect entered the distributed digital identity fray, those OpenID usability problems came into stark relief. Now, Google and Plaxo have responded with a new workflow for OpenID logins that simplifies the process and improves the usability - by adding OAuth and the Google Contacts API to the mix.
You tend to hear more about OpenID, but OAuth has its own loyal following using the protocol for authentication. OAuth has been implemented by organizations like Flickr and Netflix - and has been promised to be in the works for Twitter. Combining OAuth with OpenID offers an improved user experience by letting each technology do what it does best. The benefits of this technique are demonstrated by registering for a new Plaxo account using your Google account.
The "hybrid approach" - currently available in a limited beta - that Google and Plaxo have employed uses OpenID to sign in, then invokes OAuth for delegated authorization, and finally calls on the Google Contacts API to access information about contacts. And it does all of this transparently to the end user.
The first step in the Plaxo-Google scenario involves a new user being invited to Plaxo by a friend via Gmail. The invite understands the user is logged into the Google system and prompts the recipient with a "Sign up with my Google Account" button.

After clicking the button, the new user is directed to a Google Accounts page and asked to confirm their identity. The user is also given the option of allowing Plaxo to remember him or her in the future.

Accepting the sign-in request allows Plaxo to have access to the user's Google account credentials and the contacts associated with that account. The end result? The user now has a Plaxo account without all the rigamarole generally associated with a new account setup - and without a new username and password to track.
While the concept of site-specific logins made sense in the early days of the Web, the idea of users being forced to develop a new identity, username, password, and profile on every site they visit - including adding all the same people as connections, over and over again - seems almost laughable today. It's definitely not scalable. Especially as password requirements become more and more stringent.
With the launch of Facebook Connect, the idea of a digital identity that could follow users from site to site moved from bleeding-edge tech people to a much larger contingent of the general populous. And the ease-of-use demonstrated by Facebook Connect put some friendly pressure on the OpenID contingent to improve the way they were managing the login process.
Plaxo's and Google's demonstration is something that could improve usability for all OpenID logins, reducing the series of handoffs that tend to frustrate and confuse users. But as Eric Eldon of VentureBeat notes, there is still more to be done:
"Multi-site sign on, like what the companies are announcing today, will be more compelling when it can bring integration down to one or zero clicks, but this is certainly a step in the right direction."
This isn't a "winner takes all" pursuit or an "either/or" situation. We are participating in a Web environment where both Facebook Connect and OpenID can co-exist, because there are different applications that make both options viable and useful.
Personally, I'm not likely to use my Facebook account to access my bank and credit card accounts. But I am likely to use my Facebook credentials for social sites that would be enhanced by my existing Facebook connections. Similarly, my OpenID isn't always the right answer.
Facebook has momentum and a fervent user base. OpenID has a who's who of tech companies getting behind the concept as the preferred way to manage digital identities. Neither of these identity options are going away anytime soon.
What's best about the current situation is the rivalry between the two camps: one proprietary and easy-to-use, one open and more complex. It will be interesting to watch the two solutions push one another to become more and more simple for the end user. Because in that case, we all win.
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
That is interesting. We implemented the same strategy for the open community interface project at Mediamatic Lab. Here the flow is that people logon to a site using OpenID, whilst also approving an OAuth token at the provider. After that we do not use the Google contacts API but we do subscribe to the user's profile using XMPP. By subscribing, an Atom with the user's profile is pushed to the site and subsequent updates are pushed as well. The OAuth token is used to enable the user to update his profile, or add new contacts, whilst staying at the consuming site, enabling cross-site edits of his profile.
We think that adding XMPP publish&subscribe is essential for keeping data up to date and preventing continuous polling.
Open-CI is now live and connecting multiple social networks in the Netherlands.
See http://open-ci.nl/ for more information.
This sounds exciting. Is there a version for other sites to easily implement?
We have Google Friend Connect on our site, but it doesn't integrate with existing contact lists users have in our network, like Facebook Connect does (which we will be adding soon). What is described above seems a much closer match for and genuine rival for Facebook Connect, although it still lacks the cache of a 150 million member network behind it.
Ian Hendry
CEO, WeCanDo.BIZ
http://www.wecando.biz
Hi Ian,
All Open-CI protocols are open and public. And the key components are published. There is still some work for detailed reader friendly documentation, especially for the cross site edits and the xrds discovery format.
Ralph Meijer has written in more detail about the implementation of Open-CI:
http://ralphm.net/blog/
XMPP PubSub service:
http://idavoll.ik.nu/
XMPP/HTTP gateway:
http://idavoll.ik.nu/wiki/HTTP_Interface
Our OAuth-PHP implementation:
http://code.google.com/p/oauth-php/
You can e-mail me for more pointers or questions: marc at whatwebwhat dot com
Marc Worrell
WhatWebWhat
This process creates a Pulse account for the user, and logs them in automatically, which is great. But the problem is that they don't know how to sign in to Pulse the "normal way".
It's fine if the only time they want to use Pulse is when Hong wants to connect with them. But if they want to connect with him, they will presumably go to plaxo.com and get standard, unfriendly OpenID.
In the next release of http://www.dynamicalsoftware.com/cogenuity, we will include a Facebook Connect integration where you can send notifications via Facebook to join Cogentuity which is a challenge based social intelligence platform. I've noticed a lot of sites starting to use Facebook Connect and not always to good affect. The end user experience can be a frustrating one. Have your readers run into any friction points with web sites that integrate with Facebook?