[OT] Re: User @ domain.tld as ID (Once again)

Mike Hearn mike at plan99.net
Thu Nov 3 09:48:17 PST 2005

On Thu, 03 Nov 2005 17:24:46 +0000, Martin Atkins wrote:
> Your analogy to PNG seems to help my point because they chose to take 
> the simpler path of deciding on one way of doing it, rather than 
> providing two. Supporting email addresses and URLs is obviously more 
> complicated than supporting just URLs.

The point was that *implementations* had no choice in what to support. The
design is not layered (in that instance). Supporting email addresses and
URLs isn't all that complicated, it could probably be added to Perl/Python
implementations with a few lines of code  (supporting the fallback
remapper is a little more work, but again still pretty easy, and is a
separate discussion)

To be honest, I'm not sure that making URLs a user visible ID was a good
idea at all - to end users http://something means a website and
user at something means a person. Mixing them up like this is just leaking
implementation details, which is a usability mistake.

Sure, OpenID happens to URLs under the hood, I understand that and it's
good design. What isn't good design IMHO is forcing the user to know about
it simply because it came out of the blogging sphere where by definition
people have websites. If OpenID took off then it would leave its blogging
roots behind quickly. URLs could still work OK, but for the majority of
people with no web presence they'd be able to use the ID they were
familiar with (and as identity is personal, why does it matter if some 
people use URLs instead?)

OpenID is young and there's time for a version 2, there'd need to be one
anyway IMHO to solve things like the single sign-out problem (which isn't
hard to fix, but again needs a protocol revision). Any such new
specification could easily include a couple of paragraphs on mapping email
addresses to URLs. There's no need for a 2 paragraph extra spec. That's
just shoving the issue under the rug.

thanks -mike

More information about the yadis mailing list