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/> _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
