[OpenID] Don't you think digital identity URIs should have a specific TLD ?
Chris Messina
chris.messina at gmail.com
Thu Dec 28 20:56:05 UTC 2006
I agree with Bob and, to some extent, take some issue with the other
points on the matter, though I appreciate their intent and the matter
raised.
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). 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
More information about the general
mailing list