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.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
