[OpenID] My Suggestion for OpenID 2.1
sysadmin at shadowsinthegarden.com
Wed Apr 1 15:23:14 UTC 2009
>Before I start my suggestion I must say, there may be many ways of doing what
>ever i have suggested below. So the modalities of achieving the result is
>not really important.
From that perspective, no. From the XRI perspective, generating a
unique ID *from* the E-mail address goes against the idea of
decoupling meaningful identifiers from numeric (machine-friendly)
identifiers; XRI identifiers should be numbers that *noone* will
desire to associate with their Identity, therefore avoiding namespace
conflicts on the social level as different people compete for the
same numbers. (Also note that hashes WILL collide, it's just that
this is supposed to be mathematically improbable as an unsought
>However what is inviolable is the end result.
>"The user MUST be able to authenticate himself with OpenID using his email
>address if he so chooses to".
I'm generally allright with whatever the library does - just keep in
mind that I'll compare the final OpenID to whatever the user typed
in, and possibly parse that to understand just what it is, and then,
if it's not a URL, kill their session and show them an error message.
This is not just a trust issue, it's an identity issue. A website is
open to all, it can contain information *about* the user's identity
without requiring those investigating to identify themselves in the
process. But an E-mail address is closed, it doesn't reveal anything,
it's merely a relay point along the way to communicating with its
owner - for which, you *need* an E-mail address of your own! - who
then knows who was inquiring about them, and when, and may decide to
ignore their request for data, or even feed entirely different
information to different people. Whereas, with HTTP, even a dynamic
website will not know the identity of random visitors, thus it will
not be able to *reliably* control what information is
available/presented to different people.
More information about the general