Problems with OpenID and TAG httpRange-14

[Noah Slater]

Hello,

There are some issues with the OpenID specification and how it interoperates
with URI redirects according to RFC2616 and httpRange-14.

To use an example, take the following (work safe) URI:

  http://bytesexual.org/

This returns a 303 redirect to:

  http://bytesexual.org/about/

This returns a 200 response with the following HTML link elements:

  <link rel="openid.server" href="http://openid.claimid.com/server">
  <link rel="openid.delegate" href="http://openid.claimid.com/nslater">

The <http://bytesexual.org/> URI works as an OpenID by the specification but the
specificaion also instructs agents to "[canonicalize]" the URI by following the
the 303 redirect and so the OpenID is changed to <http://bytesexual.org/about/>.

I am arguing that this is broken according to RFC2616 and the recent findings by
the W3C Technical Architecture Group (TAG) on httpRange-14.

>From the OpenID specification [1]:

  Consumers MUST canonicalize the Identifier URL, following redirects, and note
  the final URL. The final, canonicalized URL is the End User's Identifier.

>From RFC2616 [2] (emphasis added in upper case):

  10.3.4 303 See Other

  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. The 303
  response MUST NOT be cached, but the response to the second
  (redirected) request might be cacheable.

>From the TAG's findings [3] (emphasis added in upper case):

  According to the HTTP specification, a response code of 303 indicates that
  "the response to the request can be found under a different URI ...". It
  provides the URI where we can look for that response. It's worth noting that
  although 303 has the role of redirecting user agents after script processing
  following POST requests, the specification does not limit it to that role.

  Importantly, the specification also states that "The new URI is not a
  substitute reference for the originally requested resource." IN OTHER WORDS,
  RESPONSES CONTAINING THIS CODE DIRECT US TO RELATED MATERIAL. IF WE
  DEREFERENCE THE SUPPLIED URI AND RECEIVE A REPRESENTATION, IT IS CLEAR THAT
  THE REPRESENTATION RELATES TO THE URI WE WERE GIVEN IN THE 303 RESPONSE, AND
  NOT TO THE URI THAT LED TO THE 303 RESPONSE. IN PARTICULAR, WE'RE NOT BEING
  MISLEAD INTO THINKING THAT THE ORIGINAL URI ITSELF HAS REPRESENTATIONS.

  Of course, there is no guarantee that the URI returned in the 303 will lead to
  a representation, although often it will. We need to dereference it and react
  to the resulting response. One possibility is that the URI returned in the 303
  might itself lead to further redirections. However, if we are able, eventually
  to access a representation, we can conclude that the information is related to
  the URI that originally led to the 303 response code.

[1] http://openid.net/specs/openid-authentication-1_1.html#anchor7
[2] http://www.ietf.org/rfc/rfc2616.txt
[3] http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14.html

Thanks,

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