<div dir="ltr">Bingo! This silliness of arguing over what is the correct way to represent a unique identity is like the classic data modeler's debate over natural or surrogate primary keys (see <a href="http://articles.techrepublic.com.com/5100-10878_11-1045050.html">http://articles.techrepublic.com.com/5100-10878_11-1045050.html</a>). At the end of the day, it depends on both preference and what makes sense for the given scenarios. And here we are, trying to dogmatically agree on a single method that fits every scenario.<br>
<br>I also feel there is too much new stuff out there and not enough re-use of existing technologies and methodologies. For example, in regards to the argument of centralized identity versus distributed identity, why not take a page out of the DNS book? The Domain Name System solved this problem many years ago (granted, many would argue that DNS is a bit broken, but hey, at the end of the day... it works and it works well). I'm not referring to the DNS from a technical standpoint, but from a modeling standpoint. Resolution is delegated in a distrubted manner that providers can setup as they see fit. But everything has to go through certain top-level registrars, who can then place assurances on certain things and track accountability information.<br>
<br>The same could be used for UCI - arbitrary OP's can have trust delegated to them in a distrubted fashion by a central authority whom we all agree to trust. Of course, with a single point of failure, one must ensure that root is truly trustworthy, but we all know that...<br>
<br>As for usability, I've always felt that usability becomes easier when the technology is modeled well. OpenID does not model identity well in my mind, because it uses an identifier - namely an HTTP URI - as a way to uniquely identify a human being. There is inherantly no relationship between a URI and a person, so OpenID creates one. I think more research needs to be done to determine what is the right way to do this, a lot like Eran suggests, where users can use whatever type of identifier they want.<br>
<br>Do I agree that an email address it the correct identifier? No... but it's closer than a web page URI. The argument that email addresses are a bad identifier because people may have more than one (in other words, multiple primary keys) breaks down because the HTTP URI identifier is the same thing!<br>
<br>People have a one-to-many relationship with email addresses and HTTP URI's. That makes them poor identifiers (sometimes, many-to-many with email addresses). However, email addresses are in a format that is more conducive to identification. I suspect that is a big part of why Kerberos (network single-signon) uses an email address-style identifier. Specifically, it uses userid@realm, where realm is a fully-qualified domain name. That does NOT mean that a Kerberos principal is an email address, but if one wants them to be, they easily can be.<br>
<br>Because of this, Kerberos is easy to use because it conceals all of itself! When you go to work in the morning, how many peole are aware of Activity Directory and their Kerberos tickets? None. They type in their existing usernames and passwords, or smartcards, or whatever, and the system figures it all out. When the system is modeled right, it can become automated and easy to use.<br>
<br>- Brandon<br><br><div class="gmail_quote">On Thu, Sep 25, 2008 at 6:10 PM, Eran Hammer-Lahav <span dir="ltr"><<a href="mailto:eran@hueniverse.com">eran@hueniverse.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
</span></font><ol><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Use email address in which the Identifier is separated from the Authority using the '@' character.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Use URL which points to a document containing these two values.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Use XRI which is resolved into a document containing these two values.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Ask for the Identifier and give pre-configured options for the Authority (for example pull down menu).
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Show a custom button which takes the user to the Authority and asks for their Identifier there.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Ask for the two values separately (similar to how Windows Domain login works).<br>
</span></font></li></ol><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
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:<br>
<br>
</span></font><ol><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">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.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">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).<br>
</span></font></li></ol><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
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.<br>
<br>
EHL<br>
</span></font>
</div>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br></div>