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

[John Kemp]

Dick Hardt wrote:
> 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 guess I don't understand what this 2K limit is (and this is not
mentioned in the spec) - are you talking about limits on the URL size
when doing an HTTP GET? If so, why not use POST instead?

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

As you note below, JS/AJAX-capable browsers may be present on high-end
phones, but there aren't many of those in comparison to lower-end phones.

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

Can't YADIS be used to obtain such metadata from the IdP?

- John

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