[OpenID] OpenID delegation "vs" discovery -- another "Sam Ruby 303" use case

[Boris Erdmann]

Hi,

I just want contribute another possible 303 use case:

In general I think, not every webhoster wants to become a provider,
but might want to offer their users OpenID delegation as a service. I
have put up a use case that I recently discussed at the IdentityCamp
Bremen, Germany ( slides, see here:
http://boris.jimdo.com/documents.php )

Let's take a web hoster that offers username.hoster.com webspace for
free, but where you can opt to upgrade to http://username.com/.

Now, to prevent search engines from seeing content from both domains
as content spam it is recommended to redirect from username.hoster.com
to username.com

On the other hand we do not want to redirect in case of OpenID
discovery, because we have to preserve the old identifier in order to
prevent identity loss with existing relying parties' accounts.

This totally breaks xrds-simple 5.1.2.3
(http://xrds-simple.net/core/1.0/#get_yadis, mind the .3) or even HTML
head discovery, since we assume, that this takes place when the
relying party does not send an HTTP Accept application/xrds+xml
header.

In other words: We're lost when relying parties do not mark their
request as a Yadis-Request (by doing a HEAD request or adding the
Accept header). Plaxo is a prominent example: They are perfectly
capable of processing XRDS documents, or the X-XRDS-Location header,
but they simply say "Accept: *" with their request, which we cannot
send unconditionally.

Could this perhaps be solved by Sam Ruby's interpretation of 303? We
could send search engines and UAs to the other location via 303, while
telling OpenID libs: "Hey, you have reached the claimed_identifier,
and by the way, see X-XRDS-Location or HTML head and retrieve
delegation information."

Too weird?

Boris