[OpenID] Only 303, not temp redirects (302/307), need changing

John Panzer jpanzer at acm.org
Fri Mar 7 16:26:11 UTC 2008


I can see merits in various sides of this debate.  I'd like to throw a 
few observations in:

1. OpenID is a mechanism for proving effective control over a URI.
2. A URI doesn't need to point at a web page which returns HTML...
3. ...but it almost always does, and so there are potential conflicts 
between using the URI to point at a web page and using it as an OpenID.

In other words, OpenID is _not_ free in practical terms to completely 
redefine HTTP response codes to suit its semantics, unless it wants to 
risk collisions with reasonable web page setups, such as:

A. Sam Ruby's 303 See Other in response to an XRDS metadata request, 
purely for convenience of implementation.
B. Redirecting from an insecure protocol to a secure one, necessary 
because OpenID rules demand that reasonable human-entered strings use an 
insecure protocol by default (for good reason).
C. When the underlying resource itself moves homes, perhaps to a new 
service provider, leaving a redirect (301, probably) for a while, 
ideally followed in a few months by 410 Gone Buh Bye but practically 
that's not guaranteed. 

I personally would probably become happy around any decision on 
semantics of 3xx codes, as long as the above scenarios are handled 
reasonably (from the POV of the end user) and we have _some_ way to keep 
an RP from throwing away what the user entered in their UI in favor of 
https://zx3838.example.org/cgi-bin?openid-xrds-resolver&k1=38838s838 
because that was the convenient way for the OP's site admin to set 
things up.

John



More information about the general mailing list