[OpenID] The 3xx Redirect Debate

[David Recordon]

Wow!  Just got done reading the threads both on this list and the  
specs list.  Certainly a lot of passion in the discussion and good  
points being made all the way around.  It was a little disheartening  
to see how brusk it got at times (arguing about what mailing list to  
use wasn't really moving the discussion forward).  I'm sending this to general at openid.net 
  (and will forward a copy to specs at openid.net) since the majority of  
the discussion took place on general, even though it was probably  
better suited for specs.  That said, let me see if I can help provide  
a few clarifying thoughts.

Completely ignoring technology for a moment, Noah's use case of being  
able to enter his domain and have it be displayed / treated as his  
OpenID at a Relying Party while having a browser redirect to /about/  
for normal people seems quite reasonable.  I have a gut feeling that  
this is a relatively rare practice (guessing most people don't think  
about doing it), but from a user experience perspective I like it.

 From a technology perspective, as the discussion very clearly showed,  
making this work with some form of predictable backwards compatibility  
isn't easy.  With that in mind, the number of OpenIDs that currently  
issue a 303 redirect is probably fairly small since I would imagine  
that the majority of people don't understand the difference between  
301, 302, and 303.  I know it took me re-reading RFC 2616 and  
Wikipedia a few times.

 From a historical perspective the original OpenID 1.1 specification  
said:
  > Note that the user can leave off "http://" and the trailing "/".  A
  > consumer must canonicalize the URL, following redirects
  > and noting the final URL.  The final, canonicalized URL is the
  > user's identity URL.

It, and now the 2.0 spec as well, do not differentiated between the  
type of HTTP redirect that is occurring.  Rather, an OpenID RP  
following the OpenID specification would follow any type of  
redirect(s) (making its own choice of how many is too many as RFC 2616  
infers) and then if successful treat the resulting URL as the user's  
OpenID claimed identifier.  It would then perform discovery on that  
resulting URL, looking for a provider or delegation information.   
While certainly not to the HTTP spec, I believe the original intent  
was to conflate the various types of redirects into a single meaning  
for OpenID.  Is that "right", maybe not, but it does make the simple  
cases simpler.

The largest problem I see is that in the wild there is a lack of  
consistent understanding and behavior around 3xx response codes.  A  
302 is often used when a 301 should be, a 302 is treated as a 303, and  
I doubt the difference between a 302 and a 307 is widely understood.   
301, 302, and 307 are clearly pretty similar and I do agree that a 303  
is designed to be treated a bit differently; "See Other" versus  
talking about something being found, moved, or redirected.  I could  
see the case being made that an OpenID RP should treat a 301, 302, or  
307 as a 301 (current behavior of use the final URL after all  
redirects) and then a 303 treated as a different form of OpenID  
delegation.  (Since delegation is basically saying "I'm URL A, but I  
can prove I also own URL B which I delegate to" which is similar to  
Noah's use case of "I'm URL A, but people should see me at URL B, and  
URL B delegates to my provider.")  This would add future support for  
Noah's use case while probably breaking a small number of OpenIDs.

I don't have a clear answer, but I do agree that a future revision of  
OpenID Authentication should spell out clearly what to do with these  
various 3xx codes.  I think the first step there is some real research  
into the actual use of 303 on the web as it might relate to OpenID.

Noah, thanks for bringing this up!

--David