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

[Dick Hardt]

On 17-Nov-06, at 10:38 AM, John Kemp wrote:

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

yes

> If so, why not use POST instead?

Now I am really confused about what you are talking about

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

That does not make any sense. You are stating that the user agent  
might not be able to support JS. Not supporting JS would mean the  
RP / OP would need to figure out what the user agent supported so  
that it could decide on using GET or POST.