[OpenID] The 3xx Redirect Debate

[Andy Powell]

David,
firstly, thanks for the useful summary.

Secondly, I hope that by saying:

> 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 hope you intended to mean "... should spell out clearly what to do
with these various 3xx codes and should interpret them in line with the
underlying HTTP specs".

Is that what you meant?  Or are you not willing to go that far
currently?

I think it is very important that OpenID does not work against the
underlying HTTP specs and that getting this right now is more important
than short-term backwards compatability.

Andy
--
Head of Development, Eduserv Foundation
http://www.eduserv.org.uk/foundation/
http://efoundations.typepad.com/
andy.powell at eduserv.org.uk
+44 (0)1225 474319 

> -----Original Message-----
> From: general-bounces at openid.net 
> [mailto:general-bounces at openid.net] On Behalf Of David Recordon
> Sent: 29 March 2008 08:20
> To: OpenID List
> Subject: [OpenID] The 3xx Redirect Debate
> 
> 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
> 
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>