Managers Magazine

There's nothing new here. Of course it's possible to improve the user experience by requiring(or at least, making it exceptionally difficult not to use) a few major providers. That's been done a thousand times over.

We're no closer to solving truly distributed federated identity than we were, and this if anything pushes us actively further away. I want to see interface work can serve the world, not the one or two big players in one sphere.

This experiment combines 1) creating a new account on Plaxo and entering profile data, 2) verifying your email address and 3) granting Plaxo access to your address book. Before the combination of OpenID and OAuth, you would be sent to Google two or three times: first to login with your Google Account, second (if you didn't use OpenID) to Gmail to verify your email address and third to grant Plaxo access to your Gmail address book.

Rather, this experiment with a hybrid of OpenID and OAuth combines these steps so that the creation of a new account always includes the verification of your email address and you're telling Google that you wish to provide Plaxo with access to your address book.

OpenID is still a solution in search of a problem for most individuals. We use our browsers' ability to remember credentials combined with cookies and a limited set of passwords to address this. If I only have 1 or 2 username/password combinations to remember anyway... what's the advantage of OpenID again?

This is the first time we're seeing OpenID that is driving our core business metrics. It's good for users, good for Plaxo, good for Google, and implemented in a way that can be replicated by any other sites of the web.

You're probably right, David, but I'll restate my point more fully for posterity here. Because:

1) It's extremely difficult to craft a good UX for N providers, making the button path -- used by social bookmarks and the demonstration above alike -- very appealing;
2) The data necessary to build a value proposition, like a contact book, is not available consistently from all providers;
3) There is no trust framework to support a diversity of providers.

Whatever the protocol under the seams, if the three above points are not comprehensively addressed, I see an inexorable drift towards the "Top 4" that Joseph describes. Discovery is the toughest and most important.

I'd love to see an example of this being done with LDAP, including the granting ongoing access to an API resource (the address book).

This is tangential; I'm just pointing out that I'm not emotionally attached to protocols. They grow, evolve, and die, but in the end aren't always that different from each other.

If you wanted to get imaginative with LDAP, perhaps one would provision a service DN for each application, do LDAP auth of the user at the login page, change the user's contact list ACL to permit reading by the service DN, transmit the username + timestamp to the service in a query string encrypted using the service's public key, and then perform a simple LDAP query(an API for retrieving data about a username, after all).

Obviously a dirty hack inferior to application of OAuth + OpenID, vulnerable to a few more attacks by the service, and LDAP isn't viable for inter-realm use, but it'd work.

Brainfarted the slightly important "signed" word, sorry. :D But I'd rather not let that distract from the core issue that rick articulated better than I: the UX being demonstrated here naturally constricts the OP's to a select few, so I really don't think of it as progress.

But without a doubt, the best thing to come from the meeting was this pic:

http://www.flickr.com/photos/wnorris/3270176733

ndk said:

"...If you wanted to get imaginative with LDAP, perhaps one would provision a service DN for each application, do LDAP auth of the user at the login page, change the user's contact list ACL to permit reading by the service DN, transmit the username + timestamp to the service in a query string encrypted using the service's public key, and then perform a simple LDAP query(an API for retrieving data about a username, after all)."

Exactly! That's what I want to write an Oil Can script to do, for all Android phone's ( address books in Android phones automatically sync'ed to Gmail BTW ). Decentralized and spread out out, no single point of failure.

"...A distributed architecture for social networking? Existing social networks usually employ a "hub and spoke" model, where the website is the hub of all activity within the network, and where there is a "client" and a "server". Since all traffic must pass through the hub, that site may become a bottleneck. Furthermore, each transaction must pass up one spoke to the hub, and then down another spoke, when the people interacting may be much closer to each other (in network terms) than either is to the hub site...

There is the opportunity to create an architecture that distributes the load to the devices sitting in our coats and pockets, rather than solely on massively scalable Web sites. Such an architecture would require better interoperability between social networking sites and mobile devices than we have today, and should remove any dependence on an "always-on" network connection."

http://www.w3.org/2008/09/msnws/papers/nokia-mobile-social-networking.html

I think the thing to take away from the Plaxo numbers that Joseph presented is this: if we can make the user experience as simple as two button clicks (that's really all it is), the ROI for relying parties is incredible. The beauty of the Plaxo/Google demonstration was made possible by open protocols (that really could have been anything, including LDAP), but more importantly intelligent OP discovery. It demonstrated ONE way of doing intelligent discovery -- that is, assuming that if the user used Google for their email, then there's a decent chance that they would want to use Google as an authentication provider. As their numbers show, this was a pretty accurate (although not 100% true) assumption.

The point is, if we can do intelligent discovery, the payback is huge. The true challenge, and this is what was left out of the article, but was discussed during the rest of the UX Summit, is how to do this discovery. No one is suggesting that the Plaxo/Google approach, or even the "big four buttons" approach is the end-all, be-all solution to discovery. No one is saying that. Plaxo's demonstration only underscores the importance of discovery, and it's problem we have yet to solve.

I think that's the key. Until yesterday, there had been little public discussion about streamlining the OpenID login process for those not knowledgeable of what "OpenID" is. At the end of the day, most users won't know that they're interacting with something that is using the OpenID protocol, which is the way it should be.

Facebook Connect has proven that engagement rises and that there is a higher rate of new registrations. The Plaxo example confirms this even more. This is great to see and I think we are on the verge of a breakthrough which will make all registrations as simple as two-clicks. This is awesome. OpenID ftw

Thanks, Will. Your entire message is very much the right one to carry forward here, and since I wasn't present, I'm glad to hear that more was present at the summit than just the "Top 4" buttons.

It'd be great to get more earnest communication on innovative techniques being proposed to prevent OpenID from falling further into the social bookmarking solution. No such details have leaked out of the inner circles, and when all we see is presentations like this, the discomfort of commentators not directly invested in the future of this technology is probably understandable.

I have long predicted that the next wave of social networking will be ALL sites offering social elements so "friending" and commenting and the like is available everywhere.

This, to some degree, is already happening (I spend two hours every morning reading and commenting all over the web) but it typically requires a separate identity on each site. And if I wish to make my contacts aware of the article I need to drag their butts over to that specific site first. This is all a pain.

So socialising the web will become a lot easier if a SINGLE existing identity can be used by me across the whole web. OpenID offers this. What it doesn't do today, and what Facebook Connect DOES do, is enable me to easily share what I am doing across the whole web with my friends and contacts. Well, I say FBC does do it, no one is using it yet...

And a key reason is everyone would like to see something more "Open" allowing that so they aren't tied into Facebook, which doesn't have a great reputation for protecting investments for its third party developer partners.

What Plaxo and Google are showing is exciting, but is playing functional catch up with FBC and will only geat REALLY exciting once they issue some code which you and I can integrate into our sites to offer the same functionality.

By the way, I agree with the view that is arguably leading us down the wrong road ultimately, as I would prefer to see a trusted, independent, non-profit body holding identity and social graph information, which we then "lease" to sites we visit with a few clicks. Although W3C is putting together a team to investigate this, encouragingly, it is still some way off.

Ian Hendry
CEO, WeCanDo.BIZ
http://www.wecando.biz

I agree with Ian Hendry, we need "a trusted, independent, non-profit body holding identity and social graph information, which we then "lease" to sites we visit with a few clicks."

"The Plaxo/Google approach, or even the "big four buttons" approach" will become the "the end-all, be-all solution to discovery." and I'll no longer be able to use my blog as a self-provisioned OpenID.

Sicne the the user experience weill be "as simple as two button clicks (that's really all it is), the ROI for relying parties is incredible." - @williamnorris