[OpenID] New OpenID Customer Research Activity - Googleresearch on federated login

[Peter Williams]

Lets not forget, 8000 online banking banks are identifying 80M Consumers today (just in the us). They did not standardize on a single id. The only federation notion is the obligation to share the ip of a party they have denoted as fraudulent (without stating the reason), to give 7999 others a head start in dealing with systemic attacks.

Some in the identrus banking community think that a single id will make a difference. To what problem, is the real question?

________________________________
From: Johannes Ernst <jernst+openid.net at netmesh.us>
Sent: Thursday, September 25, 2008 3:58 PM
To: OpenID List <general at openid.net>
Subject: Re: [OpenID] New OpenID Customer Research Activity - Googleresearch on federated login

I beg to differ. If only for security reasons, there's got to be one way and one way only.

I'm all in favor of many options during the research phase of R&D, but for OpenID to move into the production phase, I believe we need to do better than this.

I realize that this requires advanced sausage making skills. I hope that this community, collectively, has those.


On Sep 25, 2008, at 15:10 , Eran Hammer-Lahav wrote:

My proposal is for the OpenID foundation to take all the money it has, license as much porn as it can, and create the world’s biggest porn site ever that uses OpenID as its exclusive, free, form of entry.

Joking aside, people will learn how to use something new if they have a reason to. I wonder what the study result would have been if Google offered each test subject an extra $1000 if they figured out how to login using the more complex mockups. My fundamental problem with this discussion is that it assumes there must be a way to solve this problem that does not require user reeducation.

Federated login requires two values: Identifier (username at OP) and Authority (OP domain). The proposals we have so far to collect these two values are:


 1.  Use email address in which the Identifier is separated from the Authority using the ‘@’ character.
 2.  Use URL which points to a document containing these two values.
 3.  Use XRI which is resolved into a document containing these two values.
 4.  Ask for the Identifier and give pre-configured options for the Authority (for example pull down menu).
 5.  Show a custom button which takes the user to the Authority and asks for their Identifier there.
 6.  Ask for the two values separately (similar to how Windows Domain login works).

Let’s face it, we are not going to agree on one solution. Why? Because this community consists of two many competing interests and we have been having this exact debate on and off for over 2 years. To me this calls for a radical change in approach and here are two half-baked ideas the demonstrate:


 1.  Deal with the usability issue directly: let the OIDF board make a large and aggressive move to bring OpenID to the browser by either working directly with the major browser providers or spec out the technical requirements of how OpenID should work in the browser and offer $100K prize for the best open source add-in that works with IE, Safari, and FireFox.
 2.  Deal with the underlying technology issue: break the OpenID specification to completely separate the federation workflow from the identifier. Everyone seems to think their identifier is superior to others (email, URL, XRI, etc.), so why not let anyone create whatever identifier they want as long as there is a way to go from the identifier to the two values. This can be done by using a registry or resolver owned by the OIDF (which of course will be redundant and can use many existing technologies).

While this debate continues, business deals are being made to put those special buttons on partner sites which will eventually offer enough value to most users to make OpenID irrelevant.

EHL
_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general