As the race for an internet-wide single sign-on standard continues, Google has become the latest party to throw its hat into the ring by adding support for OpenID, along with the accompanying developer tools, to Google Accounts. Webmonkey recently had a chance to chat with Eric Sachs, Google's project manager behind its effort to incorporate OpenID into its users accounts. In a telephone interview, Sachs discusses Google's involvement in the open-source project and the challenges OpenID faces in the future.
Webmonkey: You participated in a recent UX summit at Yahoo with representatives of OpenID partners from Yahoo, Microsoft, Facebook, MySpace, Plaxo, AOL and others. What was discussed there?
Eric Sachs: Funny enough, that started off being a very small meeting between ourselves and Yahoo and AOL and MySpace because all of us had heard the same feedback from these mainstream websites. In fact, it came out of an OpenID content advisory council that OpenID board had in New York a few weeks earlier.
We had plan on sitting down and saying "OK we've heard this feedback, let's figure out how to meet it," but then this was done in the community and a lot of other people heard us and said, "Hey can we come and join?" So from Google's perspective, we're making this available as an option to relying parties sites, we still support more traditional mechanisms to get just the URL with say our Blogger Identification Provider (IdP) service, this new IdP we're offering even offers another option where websites can just request an opaque URL identifier from us if they don't need an email address from us.
We're going to give these Relying Partners (RPs) a couple different options and we really want to enable them to experiment and find out what approaches work best. We don't really feel that we as an identity provider can tell these RPs what approach works best. We really want to help them and work with the community to try and figure out which approaches work best for websites in different categories.
Webmonkey: One way Google's implementation differs from the traditional OpenID model is an authorization dialog allowing Google to share e-mail information when they log in to other sites. Why is allowing relying partner sites access to user e-mail addresses so important?
Sachs: There are a couple reasons for that. The OpenID content advisory council in New York and the OpenID board pulled together a lot of the OpenID content providers, so this is like Forbes and BBC and a lot of other major magazines and online news sites and said "Hey, you all as web sites have told us that your needs to strongly authenticate users are not particularly high. You might have content that people might pan out and send to someone else. You want pretty decent confidence of the user's identity to give them access to subscription content."
So they asked if they would all come and meet with us as the OpenID community, and tell us why aren't you adopting federated login. Why are the problems with it? and there were three primary areas of feedback they gave us at the meeting. The first was that the user interface that the identity providers had was too complex.
The second thing that those websites said was "Hey, we have a very large installed base of users who already log in to us with an e-mail address. We need to provide some user-friendly way to potentially transition them to this approach."
Near the end, the person who was leading the OpenID meeting actually specifically polled the group and said, "OK, here is a list of attributes that potentially OpenID identifiers could give to you. What do you need?" And everyone there said, we absolutely need the e-mail address, it would be nice to know if the user is over 18, if the identity provider had that information, and other than that everything else is sort of a nice to have.
That was very strong feedback from the group, and to be honest, Google, Yahoo, the others in this base, we talked to the potential relying partners last year and we've heard the same thing as well. It wasn't just within that group. So we're going to give the option for our user's experiments and see how it works for them and see what their users think of it.
Webmonkey: Microsoft, AOL, Yahoo and Google are all OpenID providers, but none of these primary internet destinations are relying partners. If everyone provides OpenID accounts, but none of them allow you to login with them, what's the point?
Sachs: Circular, right? Let's be honest here. Google is kinda half way in the middle of this as well. The one difference we have as compared to Yahoo is you can sign up with a Google account using any e-mail address that you own. You can login with a Yahoo address, a Hotmail address a Morgan-Stanley address and use things like iGoogle, Google News, Google Checkout, etc...
We don't, as of yet, allow you to log in to, say, Google Checkout, using federated login from another website and, in fact, one of the reasons for that is another piece of research we shared at the UX summit which is that large providers like ourselves and Yahoo have a lot of desktop applications and installed applications for mobile devices, and those applications are all hard-coded to ask for the user's user name and password. If someone is trying to login to Google using federated login, I as Google don't have their password so a user tries to launch Gmail on their blackberry and types in their password I don't know what to do with it. So those applications just plain vanilla break.
One of the other things that working on is with a combination of the OpenID protocol and another standard protocol called OAuth, we're trying to work a combination of the two to try and enable our rich clients applications to potentially work with federated logins. First we're actually doing that with our enterprise customers, where we already support federated login, and if that works we hope for the longer term we can offer that to consumers.
Webmonkey: Both you and Yahoo contributed user experience research suggesting OpenID's user experience is just too confusing. How are you addressing these issues?
Sachs: One of the biggest issues we've tried to figure out is: The average user, how do they learn the first time it is even possible to use federated login. Just last night after we got this stuff live, I showed the Buxfer website (a website using Google Account APIs) to my wife and I said "Why don't you login with your google account?" Just as Yahoo's research shows and our own research shows, she completely missed the Google button and tried to login the normal way.
The second hard problem is that some mainstream websites are looking at this and saying "You know what, federated login is good, but what would be really great is access to the user's social graph," so that they can enable their websites to be more socially relevant. So on a newspaper or magazine website, maybe they can tell the user, "Here are some other articles your friends liked on this site."
That's the kind of stuff that needs to be worked out, but this is why at the UX summit we said Yahoo, MySpace, Google, and others each of us has an incentive to work together to find a common approach here. Each of us has significant UI or UX resources who can do some testing. And we're all now quite willing to share our test results with each other because this isn't an area where the UI is going to be proprietary to any of us. As soon as someone finds a UI that works well, it's going to work for all of us. We all have an incentive to get there as quickly as possible. Make a big pie to go after and then we can all compete to grab a piece of that pie.
Webmonkey: The Facebook Connect interface appears to be a step ahead in user experience. Why doesn't OpenID utilize its interface solutions?
Sachs: It's certainly simpler. One of the things we should realize is that we're not the first in this space. Microsoft had Passport, was it ten years ago? Where they put a passport button on your website and you clicked on it and they tell you the user's e-mail address, their identity, you can get their address book. So to be honest, they thought of a lot of this stuff a long time ago. That single button approach had the same usability problems then that it did now.
Facebook, I mean, let's give them credit, they've done a great job thinking through the usability of the pop-up approach and in particular, and here is where we beat up on the lawyers a little bit, the approval pages on the identity providers tended to be written in very conservative legalese by the lawyers. This is one of the things Yahoo admitted in their UX research, that they just made it too complex. No users are going to read all of this stuff. So they certainly worked to simplify it in the new version that they've rolled out and they've made huge improvements.
Facebook has been even more aggressive about trying to simplify it even further. Now there's a balance there between what is enough informed user consent, what makes the lawyers happy and what's a good user interface? Facebook has certainly made users happy and it's a good user interface and it made their lawyers happy. I'm sure it gives the lawyers at some other companies the chills, but it might just be the right approach in this case.
Webmonkey: Why would there be resistance to sharing my e-mail? Is there a control issue?
Sachs: There certainly is. So one thing to note is the method we're using to give the users their e-mail address when they're on a relying partner's website is still built on the OpenID technology. It did have a standard by which the user could consent to have their address given to the other website. So that's always been OpenID. The problem is once you give your e-mail address to a website, what's to stop them from mistakenly or maliciously giving it to some spammers. The other problem is what's to keep some spammer or phisher from trying to impersonate that website, say your bank, and send you e-mail.
Now we get into some of the inherent problems of SMTP that to be honest are a bit orthagonal from anything related to federated login, but the identity and security community, boy do we wish we could avoid some of those problems of internet e-mail. I'm someone who has been in the e-mail hosting business since 1992, back when it was X400 and Lotus Notes digital signatures and back then when we looked at SMTP, we thought "no-one would ever use this" but, it was so much simpler and easier for users to use that user's said "you know what, the value proposition here far outweighs the risk." If I went to my wife today and asked her to stop using e-mail, I bet she'd shoot me. We don't have a better alternative yet. The industry is going to keep on working toward it, but that doesn't necessarily have to be solved as part of federated login. The problem is likely just related issues.
At the end of the day it's great to find these ways to maybe replace e-mail addresses for communicating with other businesses, but I don't know what you're going to do to replace communication with your friends. My friends, if I'm giving them a business card it's going to have my e-mail address on there, I don't know what else to suggest would be on there.
One of the options that has been suggested is well, what if it points to your social network web page and the person has to do a friend connection with you before they can send you e-mail. You know, maybe. Sounds like a lot of work, but maybe.
Read our featured article about OpenID's usability problems on Webmonkey.
