So we can see that running the discovery algorithm on the email address
has resulted in Yahoo's standard identifier select endpoint. What
we've actually seen here is the effect of Section
3. Otherwise, the input SHOULD be treated as an http URL; if it does
not include a "http" or "https" scheme, the Identifier MUST be
prefixed with the string "http://".
So the email address is normalised to the URL http://email@example.com
(which is treated the same as http://yahoo.com/), which is then used
for discovery. As shown above, this results in an identifier select
request so works for all Yahoo users.
I wonder if the Yahoo developers realised that this would happen and set
things up accordingly? If not, then this is a happy accident. It isn't
quite the same as having support for email addresses in OpenID since the
user may end up having to enter their email address a second time in the
OP if they don't already have a session cookie.
It is certainly better than the RP presenting an error if the user
accidentally enters an email address into the identity field. It seems
like something that any OP offering email addresses to its users should
The thing to keep in mind though is this is currently an accident, and
not a supported use case. The HTTP-fetching code in many OpenID
implementations doesn't really know what to do with the user@ part of
the URL, i.e. it'll try to use it as a hostname instead of translating
it to parameters for basic auth, and it'll break.
So you're better off just typing in "yahoo.com", really.
That's against the spec though. HTTP URLs must not have a
authentification part. That's reserved for FTP and some others.
James Henstridge -
Kevin: I agree that typing "yahoo.com" is easier and what users should
be directed to use. I just found it interesting that an approximation of
the user's intent happens if they enter their email address.
Armin: it is true that the HTTP RFC doesn't specify handling of the
userinfo portion of the authority section, but does seem to be supported
by most implementations (they probably do URI generic syntax processing
before any HTTP-specific processing). I agree that this isn't the sort
of thing that you'd want to start relying on, but it is nice that it
half works though.