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

[Dick Hardt]

On 16-Nov-06, at 11:41 PM, Matt Pelletier wrote:
> On Nov 17, 2006, at 1:24 AM, Dick Hardt wrote:
>
>> Hi John
>>
>> So that a message can be more then 2K of data.
>>
>
> Is it possible to update the language so 1) we don't deprecate HTTP  
> redirects and 2) the form redirect method is described as the  
> preferred/recommended approach, but is not required? You could even  
> stress that HTTP redirects should only be used when the HTTP  
> client's capabilities/limitations would adversely affect the  
> application behavior (or user experience, whatever language is more  
> appropriate for the spec) if form redirects were attempted.
> I agree with John on the basis that not all HTTP clients will have  
> JS functionality, whether disabled or unavailable, and whether we  
> can imagine what those clients would be or not (blackberry, mobile  
> phone, iPod, Nike running shoe, car keys). The choice to deprecate  
> HTTP redirects involves some assumptions that seem too broad:
>
> 1) Payloads will be > 2K often enough that there is little value in  
> supporting more than one way to redirect

Supporting payloads larger then 2K is a requirement. I foresee this  
to be fairly common in the future as digitally signed claims get  
moved around.

> 2) JS will be available to automate the user experience, or at  
> least that automating the user experience isn't that important.

JS is widely available now, and if not, the user needs to click a  
button, so things still work. In an AJAX world, this is pretty much a  
given now.

> 3) Deprecating functionality already built into the key spec  
> (HTTP), that is already in use in OpenID 1.x, is preferred to  
> supporting it, even though form redirects will involve more moving  
> parts and specs (ECMA / JS) to maintain the same basic user  
> experience.

Moving to one way to do things instead of two is desirable. If POST  
turns out to be a real issue in the real world, then we can revisit.  
Libraries are supporting both.

It also allows a good separation from URL parameters private to the  
RP and request parameters intended for the OP.

>
> What do you think?

How would you suggest the servers determine wether to use GET or POST?

>
> Dick, do you have a list of the browsers you tested against?

We tested on a TREO and high end Nokia and Sony Ericson. The types of  
phones that people could do HTML browsing with. WAP is out of scope.