Proposal: OpenID Connect
December 8, 2008
OpenID needs to be as simple as Facebook Connect if it has any chance of competing. The problem is User Experience. It’s a nightmare.
My proposal:
- All Email providers and OpenID Consumers (particularly Gmail, Hotmail and Yahoo Mail) implement: http://eaut.org/
- Until we have critical mass with step 1, a 3rd party, community controled “Email to OpenID mapping service” should be provided. Vidoop runs a related service at http://emailtoid.net/. It’s quite good but it should be donated to the OpenID foundation for independent control.
- OpenID Connect login prompts ask for your email address on 3rd party sites.
- When you hit ‘connect’ it generates a popup much like the FB Connect popup.
- The contents of the popup is either:
- The password screen of the OpenID provider as resolved via EAUT OR
- The password screen of the OpenID provider as resolved via the community EmailtoID service OR
- A prompt from the EmailToID service that walks you through creating a new OpenID or mapping an exiting OpenID to this email address.Here’s the important part: In all cases, the screens MUST conform to a strict UX Design Guideline set forth by the OpenID Foundation to ensure the process is as simple as Facebook Connect.Only providers that confirm to this OpenID Connect UX standard (as certified by the OpenID Foundation?) may have their OpenIDs validated in this popup. This is a harsh rule but it ensures a smooth UX for all involved.
- This initial Email to OpenID mapping through a 3rd party service is painful since most email providers and OpenID consumers do not use EAUT yet.
- This can be overcome if we get a series of OpenID Consumers and OpenID Providers involved as launch partners. A major email provider (Gmail, Hotmail and/or Yahoo) would also be be helpful but not a blocker.
Potential Concerns:
- How do we deter phishing? Does this work-flow make phishing worse because of the predictable UX? Does it matter? Is there a way to ensure a distributed karma system is included in the work flow?
- This only solves the login problem and does not go into the issue of connecting to, accessing and manipulating data as the full data portability vision describes. This is a conversation for another thread.
Bonus:
- If you provide OpenID but do not consume it you need to be named and shamed. There should be a 2 month grace period, then The OpenID Foundation, the DataPortability Project and everyone else who is interested should participate.
- “OpenID Connect” should be a new brand with a fresh batch of announcements with strict implementation guidelines (not just around UX but also around things like consumption).
To summarize, my proposal world:
- Allow users to use their email address for OpenID
- Standardize the User Experience for OpenID
- Provide a stop gap while Email providers catch up with Email to OpenID mapping.
Get involved:
I’d love to do mockups for this – but I’m busy. Anyone interested in learning from the Facebook Connect UX and drafting OpenID Connect Mockups from which we can draw the strict UX guidelines I mentioned?
Could this work?
December 8, 2008 at 4:01 am
Google Friend Connect gives a simple UI for any site to become an OpenID relying party without having to write any server-side code, just embedding Javascript.
This is up and running now – add it to your site via http://google.com/friendconnect
Unlike your demands for implementations of specs, it builds on existing sites, but particularly favours those with Open Stack implementations that follow openID, Oauth, Paortable Contacts and OpenSocial.
It did support Facebook too, until that was unilaterally disconnected.
December 8, 2008 at 4:06 am
Friend Connect still requires OpenID URLs for OpenID login. Also as much as we all love Google, I think it being the pinch point of the the web authentication platform defeats the purpose of distributed Identity.
The point here is to:
1. Remove OpenID URLs from the equation.
2. Remove any single pinch point.
December 8, 2008 at 4:15 am
+1 to removing OpenID’s from the equation; I think they need to exist for the sake of things-to-come with discovery for other services but users shouldn’t have to know them.
Vidoop would love to donate Emailtoid.net to the OpenID community … we stood it up just as a stop gap but we don’t want/need to control it; we just want the solution out there.
December 8, 2008 at 4:21 am
Friend Connect supports OpenID 2.0 directed identity, so you can just use the domain, and enter your email account on the host site (which is less phishing-prone, per potential concern 1). EAUT might be an alternative for those who enter email addresses, once there are implementations to run against.
Google Friend Connect isn’t meant to be a pinch point, it’s a utility implementation for webmasters that builds on Open Stack standards, which I thought was what you were asking for.
It also solves potential concern 2, by integrating with PortableContacts and OpenSocial Activity Streams implementations.
December 8, 2008 at 4:21 am
Agreed Scott.
What is your feedback about this specific course of action to achieve that result.
My proposal would.
1. Allow users to use their email address for OpenID
2. Standardize the User Experience for OpenID
3. Provide a stop gap while Email providers catch up with Email to OpenID mapping.
In fact, I will post that summary to the end of my post
December 8, 2008 at 4:27 am
@Scott
Btw good to hear that Vidoop would donate Emailtoid.net to the OpenID Foundation.
Would they (or others) be able to donate time to ensure that it ran inside the popup and conformed with whatever look and feel was rendered for the overall work flow?
December 8, 2008 at 4:28 am
@Kevin I know that Google’s Friend Connect is trying to provide utility to users. It’s certainly much better than anything Facbeook has put out there (or anyone else for that matter).
I’m just trying to come up with a generic implementation that others can implement.
Also, to continue Google’s leadership in this area, would you reach out to the Gmail team for us and get an official word about their response to this suggestion – particularly Gmail’s ability to implement EAUT.
December 8, 2008 at 5:34 am
What about the JanRain implementation of RPX. It has some good ideas for UI implementation. Not quite the proposal above but an alternative.
December 8, 2008 at 5:54 am
I applaud the goal of this post, which is to bring the OpenID adoption and UX up to the same standard as Facebook. However, the proposed means are very top-down … public shaming, seriously? The 99.9999% of users on the internet who don’t read the blogs of the top OpenID contributors won’t particularly care if they complain. If anything, the attempts at public shaming reduce the credibility of the shamers, in general.
I disagree with your statement that not having a major launch partner is not a blocker. With Facebook Connect, we considered the needs of major launch partners above all else, with the theory that if we satisfied them, then the rest would follow. The opposite is not true. If you come up with UX standards for email based verification and can’t convince either Google, Yahoo, or Microsoft to comply, then they don’t represent useful standards.
Finally, OpenID is just one piece of the puzzle of federated identity, and it is not an end unto itself. The best, best, best possible way to increase OpenID adoption is to increase the value of that adoption to the relying parties. Facebook Connect is valuable because Facebook has the most accurate names, accurate profile pictures and info, and a powerful distribution platform, not because it offers a standard. One easy way to provide value is to implement email verification through OpenID. The send-an-email-click-a-link loop is a big pain point for most websites; eliminating that would provide huge value and encourage adoption.
On a sidenote, RPX is a really great step towards the direction of providing usability, although it still suffers from the redirect stuff. Facebook developed some pretty intense technology to put it all in a popup and it has paid off big time in UX.
December 8, 2008 at 6:25 am
Chris, points 1 and 2 of your summary contradict each other. While it’d be great to have everyone map e-mails to OpenID URLs, that is not the status quo. OpenID Connect would not standardize the UX for OpenID.
Introducing a new UX for OpenID consumption is just going to create more confusion about what OpenID is. People may start to think that their e-mail address _is_ an OpenID after using it for OpenID Connect, and be confused when asked for a URL on other sites.
Ostensibly you’d get around this by making “OpenID Connect” a new brand, but can we get enough people to buy in to _another_ brand right now?
I think time and energy would be better spent selling the idea of OpenID URLs to end-users. Maybe that brand is what deserves another push.
December 8, 2008 at 6:30 am
Luke, I agree – the true value of OpenID comes when the verified URLs it provides can be used to discover further endpoints to access names, profile pictures, contacts and activity streams.
We have open standards for each of these, in PortableContacts and the OpenSocial Activity Streams spec, built on existing standards such as OAuth and AtomPub – what people have been calling the Open Stack.
I hope you can convince the rest of Facebook that your users’ trust in your data accuracy means you have nothing to fear from interoperating via open standards, as a complement to your tightly-integrated proprietary libraries.
December 8, 2008 at 9:11 am
I am really not sure if an email mapping is the best way.. I think it mainly will confuse people of what OpenID actually is. I blogged about this recently here: http://mrtopf.de/blog/web20/the-openid-branding-problem/
Then of course just OpenID is not the whole solution, what fb connect provides is maybe more comparable to OAuth with OpenSocial than OpenID (wait, wasn’t OAuth/OpenSocial what Data Availability is?
what’s missing there is maybe a PUT on the activity stream and some better packaging).
@Luke: As for “accurate names”: This might be a business factor but as a user I certainly want to choose though under what identity (be it real or not) I am logging in to a site. I even might want to have different ones to choose from.
I agree though that launch partners are very important.
The main problem with a more generic connect solution is of course what to type into that field. Not every URL is OpenID/OAuth enabled, not every email is mapped to something. Here some clever UX solution with lots of education of the user is needed and a good strategy what to do if the given term is not resolvable to a useful endpoint.
December 8, 2008 at 12:03 pm
Not a big fan of EUAT. Nothing wrong with it in principle: just the XRDS stuff which is a pain in the ass.
December 8, 2008 at 8:00 pm
One of the new features that is being explored in OpenID 2.1 will be the ability for users to Sign in with their Email address. Yahoo and a few of the other OpenID Providers have been working together on improving the user experience. Google in particular has been very generous in sharing their usability research regarding the effectiveness of having users sign into sites using their email address.
December 9, 2008 at 6:01 am
[...] Proposal: OpenID Connect « Paying Attention (tags: openid identity) Posted under Daily Links [...]
December 9, 2008 at 7:48 am
[...] Projekt in MySpaceID umbenannt hat ist der Name OpenID vielleicht doch gar nicht so doof… Ob Connect oder ID (oder sonst wie), die Funktionsweise von OpenID wird durch eine Umbenennung sicherlich [...]
December 9, 2008 at 4:22 pm
[...] su OpenSocial e su alcuni open standards (OpenID, OAuth, ecc.). OpenID dovrà sviluppare un OpenID Connect. MySpace intanto annuncia MySpaceID, a base OpenSocial, OAuth, OpenID, nonché Google Friend [...]