OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

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 at openid.net
> http://openid.net/mailman/listinfo/specs
>