[OpenID] URL normalization issues

[Josh Hoyt]

On 3/23/07, John Panzer <jpanzer at aol.net> wrote:
>
> Here's another fun one (actually got bit by this last month) which is apparently normalized client side in browsers:
>
>  http://example.org/foo/../  vs.  http://example.org/
>
>  In general I think there is a server best practice here which involves returning 200 OK only for one canonical version of a URL, and 301's or 404's for any other variants.  And a best practice for clients is to not rely on the Java URI class for equivalence checking :).

The OpenID spec relies on RFC3986's normalization rules, which cover
all of these cases. It's pretty straightforward to implement straight
from reading the RFC (though it is sad that the Java URI class does
not implement these rules!).

Regarding OpenID provider best practices, I agree wholeheartedly. Any
URL that responds with a valid OpenID discovery response *is* an
identifier, so responding to more than one URL that way effectively
creates more identifiers. Providers (and users hosting their own
identifiers) should be careful to respond with 200 OK and OpenID
discovery information only to those URLs that are intended to be
identifiers.

One of the problems with XRDS discovery (formerly known as Yadis) is
that it makes it difficult to avoid serving more than one URL that can
be used as an identifier: the XRDS file's URI is *also* a valid
identifier. You can observe this problem if you have a MyOpenID.com
account by trying to sign in somewhere that supports XRDS discovery
(i.e. not LiveJournal) with <http://youraccount.myopenid.com/xrds>.

I have yet to come up with a solution to this particular problem that
I consider satisfactory.

Yuck. I just tried it on Jyte, LiveJournal, and ClaimID, and they all
do different things with the /xrds version, so it'd be *really* nice
if we could come up with at least a decent way of avoiding this
problem.

Josh