On 19-Nov-06, at 3:08 PM, Adam Nelson wrote:
Great start on the Wiki. Note that there are some efforts in IETF for
enhancing what can be done at the TLS layer for authentication which
would enable the same mechanism to be used not only for HTTP, but for
SMTP, POP3, IMAP ...
Hmm, that's
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
Dick Hardt wrote:
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
Hi,
Sorry I'm just reading this, but I just wanted to put in a point very
much in favour of NOT deprecating support for HTTP redirects in OpenID 2.0.
I'll note that requiring the user to press a 'submit' button to push
seems like a dodgy UI strategy. So then you require JavaScript to
produce a
Hey Adam,
Thanks for the insight! I know, as Dick described, there was a design
decision made in terms of enabling payloads larger than 2Kb within
OpenID Authentication requests and responses. With that said, there are
other approaches, such as using GET requests and including a token to
Hi Adam
The switch from GET to POST was made so that we were not constrained
by the URL parameter payload limit.
As you point out, HTTP headers can be used for moving messages as
well, but there was no clear mechanism to do that without modifying
all the widely available browsers.
I think
Hi Dick:
I think REST support is a really useful feature, and have described
how that might happen in the past, but right now we are pretty
focussed on getting browser based auth finalized, and I think the
mechanisms for rich clients will be related, but slightly different.
That all makes
