[OpenID] Don't you think digital identity URIs should have a specific TLD ?

Fri Dec 29 02:53:18 UTC 2006

Let us first take a step back to put this conversation in context:

> OpenID, as I understand it, is first and foremost a protocol for
> authentication -- way to link two accounts at different endpoints
> through the use of a URL. As has been said, this doesn't constitute
> real trust, only that a relationship exists.
>
> Second, the robustness and integrity of any identity or authentication
> system will always be in question so long as the universe continues to
> expand and contract; what digital identity allows for is the
> acceleration of the conjoining of services that formally were split
> against the person, rather than the service.
>
> So, to your point, we need at least one consistent way to represent an
> identity in a system. With OpenID 2.0, there are now 3 (from what I
> remember at IIW).

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.

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  (http://www.flickr.com/photos/chrisheuer/57583696/)
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 -
http://www.windley.com/archives/2005/10/yet_another_dec.shtml.

Notes from a followup 5 hour meeting can be seen here on Johannes blog
http://netmesh.info/jernst/2005/12/02.

Yadis 1.0 <http://www.yadis.org/> is the outcome of 6 months of work dating
back to last fall's Internet Identity
Workshop<http://www.windley.com/events/iiw2006a/announcement>where
Johannes Ernst, creator of
LID <http://lid.netmesh.org/>, and Brad Fitzpatrick and David Recordon,
creators of OpenID <http://openid.net/>, proposed using a simple service
discovery format so sites could deploy a single "intelligent" login box that
could accept either LID and OpenID URLs. -
http://www.equalsdrummond.name/index.php?p=61

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 "

We see OpenID as being an umbrella for the framework that encompasses
the layers for identifiers, discovery, authentication, and a messaging
services layer that sits atop and this entire thing has sort of been"
dubbed "OpenID 2.0".-
http://lists.danga.com/pipermail/yadis/2006-June/002631.html

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.

Nothing precludes there being more possibilities
> added to the spec, though each additional identification method beyond
> the standard form that URL fields accept decrease the level of
> interoperaibility and likelikhood that you're going to see either
> widespread support or deployment of such a custom scheme in the wild
> simply because the support costs and the complexity of communicating
> which schemas are supported by each provider goes up.
>
> In this way, single pointer models like BBAuth or GAuth actually lower
> support costs by narrowing the barrels through which identities flow
> and simplifying risk in the mind of the user and iDP (presumably
> yahoo.com and google.com will be around for some time and, like Visa
> or Mastercard, and are likely "good enough for my lifetime").
>
> Now, this is where the notion of using a specific TLD looks useful to
> the intentionally fragmented OpenID community, but where mandating
> such a behavior would actually prove counter-productive. That any
> URL/i-name endpoint can be used as an OpenID puts a great deal of
> responsibility on the end user, the kind that has seldom afforded to
> date on the wild web. That I can use my own personal web address as my
> openid, or anything else that I *delegate* to act on my behalf (like I
> do with banks or credit cards) is a huge benefit, not unlike our
> ability to get up and move our physical addresses. And, furthermore,
> any permanance is really only permanant so long as there is an
> institution to afford protection or some kind of persistent memory or
> record to prove the original meaning. Anyway, this is all esoteric
> nonsense.
>
> I think my more important points are that 1) adding more conditions to
> the protocol, at this point, would delay adoption and 2) that doing
> anything outside the norm from what people are already used to (using
> a url as your identifier is weird enough) would also limit adoption
> (and .name TLDs are awkward).
>
> Ok, the end. I shouldn't write these tomes in a mall on my crackberry.
>
> Chris
>
> On 12/27/06, Bob Wyman <bob at wyman.us> wrote:
> > On 12/27/06, Drummond Reed <drummond.reed at cordance.net> wrote:
> > > XRI infrastructure solves this problem by explicitly supporting
> > > reassignable identifiers (i-names) and persistent identifiers
> > > (i-numbers) and permitting the resolution of any reassignable
> > > i-name to be mapped immedidately to a synonymous
> > > never-reassigned i-number which can be safely stored by an
> > > OpenID Relying Party without exposing the identity owner to the
> > > risk of having their i-name "taken over".
> >
> > The XRI Syntax specification says that a Persistent Identifier is "An
> > identifier that is permanently assigned to a resource and intended never
> to
> > be reassigned to another resource." While it may well be the "intention"
> > that such persistent identifiers are never to be reassigned, one must
> accept
> > that an "identity owner" is, in fact, exposed to some "risk of having
> their
> > i-name 'taken over'" in the case of unintended events. There is nothing
> > technical which prevents the taking over of XRI persistent identifiers.
> The
> > only thing that reduces risk here is people's and organization's
> willingness
> > and ability to follow the rules. Such trust may well be reasonably held,
> but
> > there remains an ineradicable risk of entities' failure to perform as
> > intended... (Note: The previous comments should not be taken as a
> criticism
> > of  XRI. This 'risk' is an inevitable characteristic of this class of
> system
> > and of this type of "solution".)
> >
> > bob wyman
> >
> >
>
>
> --
> Chris Messina
> Citizen Provocateur &
>   Open Source Ambassador-at-Large
> Work: http://citizenagency.com
> Blog: http://factoryjoe.com/blog
> Cell: 412 225-1051
> Skype: factoryjoe
> This email is:   [ ] bloggable    [X] ask first   [ ] private
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20061228/89215664/attachment-0002.htm>