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

[John Kemp]

Johnny Bufu wrote:
> 
>> 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".

And the alternative is for the user to press the 'submit' button. I'd
hope we can allow for implementations to avoid that, by offering a
redirect option.

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

No, you're right about that. We'd want to architect a piece of protocol
that provides a good user experience for as many user-agents as possible.

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

My point is that an implementation can offer BOTH profiles, and in cases
where it's likely that the browser cannot do JS, it's possible for the
RP to attempt one instead of another. Again, this is about being
tolerant of different browsers.

- John