[OpenID] Problems with OpenID and TAG httpRange-14

[Noah Slater]

On Tue, Mar 04, 2008 at 02:09:49PM -0500, John Kemp wrote:
> I don't think it's incorrect to use the final, canonical URI as an
> identifier for the OpenID user.

RFC 2526 disagrees with you:

  The response to the request can be found under a different URI and
  SHOULD be retrieved using a GET method on that resource. This method
  exists primarily to allow the output of a POST-activated script to
  redirect the user agent to a selected resource. THE NEW URI IS NOT A
  SUBSTITUTE REFERENCE FOR THE ORIGINALLY REQUESTED RESOURCE.

Also, I disagree your use of the word canonical, it is only canonical insofar
as it is a misinterpretation of HTTP 1.1 redirection.

> And if the content of the related page is an XRDS document you got by
> following redirects from the originally-provided identifier to the final
> identifier, then it would seem to me that the content of that is at
> least potentially cacheable - unlike any content you dereferenced from
> the original identifier.

I'm not interested in the cachability of resources only the canonicalisation
process that the OpenID specifcation requires being in contradiction to HTTP.

> A possible problem *might be* that the user might see content from a
> different location than the location shown in the address bar of their
> browser. That seems like a general problem with using redirects for
> protocols like this, and isn't solely linked to the "following
> redirects" part of creating a canonical OpenID.

No, I don't mind people visiting <http://bytesexual.org/> and being visibly
redirected to <http://bytesexual.org/about/> but I do mind it when OpenID agents
incorrectly canonicalise and publish an incorrect identity.

> Where do you see problems?

I see problems when OpenID does not allow me to assert a URI as my identy.

OpenID should update the spec so that canonicalisation stops at a 303 redirect.

I think Sam Ruby would like the same to apply to 302 but that is seperate.

Thanks,

--
Noah Slater <http://bytesexual.org/>