Hello, Although I agree with you about the contents of RFC2616, I don't see why there is a need to restrict OpenID to requiring POSTs of HTML forms.
It's both reasonable to have a redirect profile with HTTP GET (especially if it's possible to restrict the message size by specifying a minimum required message that will suffice) and also to have a HTTP POST redirect method (see SAML 2.0 HTTP POST/Redirect bindings [1] for one that is deployed). It's also possible to determine from the user-agent string whether you're working with a limited browser, and should use one thing or another. My point is still that in general, implementations should be tolerant of limited user-agents, and that means supporting functionality that doesn't require JS. More specific comments are inline below: Regards, - John [1] http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf (PDF) Johnny Bufu wrote: > On 17-Nov-06, at 7:17 PM, John Kemp wrote: > >>> - According to the HTTP RFC, user agents receiving a 3XX redirect in >>> response to a POST request MUST NOT automatically redirect the >>> request. >>> >> Yup, if you use a 302 redirect, which is probably what you'd want, >> then >> there is that potential. You can use 303 or 307 (as mentioned in 5.2.1 >> of draft 10 of the spec.) in order to better control that. >> > > I see that the "MUST NOT automatically" applies to all redirects: > 301, 302, 303 and 307 (sections 10.3.2, 10.3.3, 10.3.4, and 10.3.8 of > RFC2616). > Agreed. I'm not sure how many user-agents actually comply with this rule though, as POSTed redirects seem in general quite common, and in my experience anyway, seem to take place without my being asked whether I want to accept the redirect. > >>> - See the note in RFC: even though the user-agents aren't supposed to >>> change the method, some perform a GET on the redirect URL, even >>> though >>> the initial request was a POST. >>> >>> - In the specific case of OpenID authentication messages, the server >>> issuing the redirect needs to send data (the OpenID message) to its >>> peer, via the user agent. I don't see how the user-agent can be >>> instructed via a redirect to use the POST response at the redirect >>> URL. >>> >> Wouldn't the IdP would issue also a 302 redirect with its response >> message to the RP? >> > > Not to the RP directly; the user-agent would receive the IdP's > response, but it wouldn't have a way of POSTing it to the RP. > > (The same applies to auth request messages, in the opposite direction.) > The IdP would issue a 302 redirect back to the RP, through the user-agent. > >> Of course, the RP would have to remember what >> location the user-agent originally requested, in order to give the >> right >> content to the user-agent. >> > > The content (IdP's response) never reaches the RP in this case; it > ends up in the user-agent. > Even if the IdP issues a HTTP 302 redirect, with the Location header set to the OpenID response endpoint for the RP? > >> As far as I can tell, HTTP redirects are already supported in some >> current (pre 2.0) OpenID implementations, so I'm still not sure >> what the >> problem is with allowing HTTP redirect implementations in OpenID 2.0. >> > > HTTP redirects work with pre 2.0 (and 2.0), but only with GET > requests and the parameters encoded in the redirect URL. > > I don't see how HTTP redirects can work with POSTs, which is why I > believe the solution was to use POSTs and HTML FORM redirection in 2.0. > The SAML 2.0 HTTP POST binding may be used with the SAML 2.0 HTTP Redirect binding ([1]) to offer this functionality. I imagine it's possible for OpenID to do something similar. > > Johnny > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs