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
to
retrieve more data via OpenID DTP as a back-channel request. So lots to
think about...
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Adam Nelson
Sent: Sunday, November 12, 2006 5:25 PM
To: specs@openid.net
Subject: OpenID Auth 2.0 and user-agent
I've been tracking OpenID auth from 1.0 with great interest. Last
summer Johannes Ernst explained to me how it was that one might use
openid to authenticate a non-interactive user agent such as a REST API
consumer by intercepting the RP's redirect and providing the info from
the IdP itself.
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
