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

Johnny Bufu johnny at sxip.com
Sat Nov 18 20:14:46 UTC 2006


On 18-Nov-06, at 6:26 AM, John Kemp wrote:
> 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.

POSTs are required so that there are no size limitation for the  
parameters.

HTML forms is the method chosen to pass the data; the SAML HTTP POST  
binding also seems to be using forms.

> 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.

JS is not required; this is stated in the third paragraph of the  
'Abstract' section.

The 'HTML FORM Redirection' section says that "Form submission MAY be  
automated using JavaScript".

>> 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.

Still, we wouldn't want to architect a piece of the protocol to rely  
on the non-conformance of other players with the HTTP protocol, no?

>> 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.

The redirect URL would be the RP endpoint, but again I say that the  
response payload never reaches the RP; it ends up in the user-agent.

Maybe you can provide an example (headers + body) of such a HTTP  
redirect, which given in response to a POST will have the user-agent  
POST the payload (the OpenID message) to the redirect URL (RP) ?

>> 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?

Yes.

>>> 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.

I read the HTTP Redirect binding and HTTP POST Binding sections in  
the document you referenced.

- The HTTP Redirect Binding passes the parameters around encoded in  
the redirect URL (subject to size limitations), similar to OpenID's  
HTTP redirect + GET method.

- The HTTP POST Binding uses HTML forms to pass the data (again  
similar to OpenID's HTML FORM Redirection). Furthermore, the example  
from the HTTP POST Binding contains the following:

	<strong>Note:</strong> Since your browser does not support JavaScript,
	you must press the Continue button once to proceed.

It is mentioned that the two methods may be composed, but I still  
don't see how the POST form submission can be automated (without  
JavaScript). Have I missed that part?

Johnny



More information about the specs mailing list