<br><br>Let us first take a step back to put this conversation in context:<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">OpenID, as I understand it, is first and foremost a protocol for
<br>authentication -- way to link two accounts at different endpoints<br>through the use of a URL. As has been said, this doesn't constitute<br>real trust, only that a relationship exists.<br><br>Second, the robustness and integrity of any identity or authentication
<br>system will always be in question so long as the universe continues to<br>expand and contract; what digital identity allows for is the<br>acceleration of the conjoining of services that formally were split<br>against the person, rather than the service.
<br><br>So, to your point, we need at least one consistent way to represent an<br>identity in a system. With OpenID 2.0, there are now 3 (from what I<br>remember at IIW). </blockquote><div><br>This whole thread inspired me to reflect on the history that got us to
OpenID 2.0. As a non-technical person who has been part of creating
the container for these conversations about convergence to happen this
is how I trace the history. I hope that others can chime in with
elements that I might have missed.<br><br>OpenID"2.0" as it is today is really the convergence of there three (plus a fourth later) ways of doing URL/XRI based identity that were all potentially going to go to market and 'compete' they all came to the realize they all might loose or at least confuse the market for several years. Given the similarity of their vision and intent conversations began in earnest leading up to, at and following the Internet Identity Workshop in October 2005. (LID, OpenID, i-names/XRI with Sxip joining this summer). In this convergence discussion (
<a href="http://www.flickr.com/photos/chrisheuer/57583696/">http://www.flickr.com/photos/chrisheuer/57583696/</a>) there was agreement that there should be one box that users would be faced with they would be able to put in the identifier of their choice that would do the kind of authentication they wanted. This needed a service discovery protocol - it turned out that the XRI spec had and XML -based XRDS document as a way of doing service discovery would be good to use to help this convergence - it was already part of the XRI specs and special effort was made by the XRI technical committee at OASIS to adapt the spec not have it be dependent on or specific only to XRI's and to meet the needs of this use case. This new converged effort was called Yadis -
<a href="http://www.windley.com/archives/2005/10/yet_another_dec.shtml">http://www.windley.com/archives/2005/10/yet_another_dec.shtml</a>. <br><br>Notes from a followup 5 hour meeting can be seen here on Johannes blog <a href="http://netmesh.info/jernst/2005/12/02">
http://netmesh.info/jernst/2005/12/02</a>. <br><br><a href="http://www.yadis.org/">Yadis 1.0</a> is the outcome of 6 months of work dating back to last fall's <a href="http://www.windley.com/events/iiw2006a/announcement">
Internet Identity Workshop</a> where Johannes Ernst, creator of <a href="http://lid.netmesh.org/">LID</a>, and Brad Fitzpatrick and David Recordon, creators of <a href="http://openid.net/">OpenID</a>,
proposed using a simple service discovery format so sites could deploy
a single "intelligent" login box that could accept either LID and
OpenID URLs. - <a href="http://www.equalsdrummond.name/index.php?p=61">http://www.equalsdrummond.name/index.php?p=61</a><br><br>Things continued to evolve there was the second IIW in May of this year some where along the way was agreed that all this work would become OpenID
2.0 "<pre>We see OpenID as being an umbrella for the framework that encompasses<br>the layers for identifiers, discovery, authentication, and a messaging<br>services layer that sits atop and this entire thing has sort of been"
<br>dubbed "OpenID 2.0".- <a href="http://lists.danga.com/pipermail/yadis/2006-June/002631.html">http://lists.danga.com/pipermail/yadis/2006-June/002631.html</a><br></pre><br>I hope that this can facilitate some understanding that
OpenID2.0 is not just 'everyone' deciding that OpenID was the winner and all joining but a way that all these committed and what I see to be truly amazing individuals came together and worked really hard in what I think of as community building "struggle" over more then a years to get convergence. This new thing - a product of all their work is what has the potential to really become an identity layer for the web.
<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Nothing precludes there being more possibilities<br>added to the spec, though each additional identification method beyond
<br>the standard form that URL fields accept decrease the level of<br>interoperaibility and likelikhood that you're going to see either<br>widespread support or deployment of such a custom scheme in the wild<br>simply because the support costs and the complexity of communicating
<br>which schemas are supported by each provider goes up.<br><br>In this way, single pointer models like BBAuth or GAuth actually lower<br>support costs by narrowing the barrels through which identities flow<br>and simplifying risk in the mind of the user and iDP (presumably
<br><a href="http://yahoo.com">yahoo.com</a> and <a href="http://google.com">google.com</a> will be around for some time and, like Visa<br>or Mastercard, and are likely "good enough for my lifetime").<br><br>Now, this is where the notion of using a specific TLD looks useful to
<br>the intentionally fragmented OpenID community, but where mandating<br>such a behavior would actually prove counter-productive. That any<br>URL/i-name endpoint can be used as an OpenID puts a great deal of<br>responsibility on the end user, the kind that has seldom afforded to
<br>date on the wild web. That I can use my own personal web address as my<br>openid, or anything else that I *delegate* to act on my behalf (like I<br>do with banks or credit cards) is a huge benefit, not unlike our<br>ability to get up and move our physical addresses. And, furthermore,
<br>any permanance is really only permanant so long as there is an<br>institution to afford protection or some kind of persistent memory or<br>record to prove the original meaning. Anyway, this is all esoteric<br>nonsense.
<br><br>I think my more important points are that 1) adding more conditions to<br>the protocol, at this point, would delay adoption and 2) that doing<br>anything outside the norm from what people are already used to (using
<br>a url as your identifier is weird enough) would also limit adoption<br>(and .name TLDs are awkward).<br><br>Ok, the end. I shouldn't write these tomes in a mall on my crackberry.<br><br>Chris<br><br>On 12/27/06, Bob Wyman <
<a href="mailto:bob@wyman.us">bob@wyman.us</a>> wrote:<br>> On 12/27/06, Drummond Reed <<a href="mailto:drummond.reed@cordance.net">drummond.reed@cordance.net</a>> wrote:<br>> > XRI infrastructure solves this problem by explicitly supporting
<br>> > reassignable identifiers (i-names) and persistent identifiers<br>> > (i-numbers) and permitting the resolution of any reassignable<br>> > i-name to be mapped immedidately to a synonymous<br>> > never-reassigned i-number which can be safely stored by an
<br>> > OpenID Relying Party without exposing the identity owner to the<br>> > risk of having their i-name "taken over".<br>><br>> The XRI Syntax specification says that a Persistent Identifier is "An
<br>> identifier that is permanently assigned to a resource and intended never to<br>> be reassigned to another resource." While it may well be the "intention"<br>> that such persistent identifiers are never to be reassigned, one must accept
<br>> that an "identity owner" is, in fact, exposed to some "risk of having their<br>> i-name 'taken over'" in the case of unintended events. There is nothing<br>> technical which prevents the taking over of XRI persistent identifiers. The
<br>> only thing that reduces risk here is people's and organization's willingness<br>> and ability to follow the rules. Such trust may well be reasonably held, but<br>> there remains an ineradicable risk of entities' failure to perform as
<br>> intended... (Note: The previous comments should not be taken as a criticism<br>> of XRI. This 'risk' is an inevitable characteristic of this class of system<br>> and of this type of "solution".)
<br>><br>> bob wyman<br>><br>><br><br><br>--<br>Chris Messina<br>Citizen Provocateur &<br> Open Source Ambassador-at-Large<br>Work: <a href="http://citizenagency.com">http://citizenagency.com</a><br>Blog:
<a href="http://factoryjoe.com/blog">http://factoryjoe.com/blog</a><br>Cell: 412 225-1051<br>Skype: factoryjoe<br>This email is: [ ] bloggable [X] ask first [ ] private<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">http://openid.net/mailman/listinfo/general</a><br></blockquote></div><br>