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

[Recordon, David]

I've chatted with Brad a decent amount about this over the past few
weeks, but still am unsure of what the "right" thing to do here is.  The
reason behind deprecating GET and using POST instead was so that larger
payloads could be moved (it is commonly agreed upon not to move over 2K
of data via a GET URL) without having to deal with both GET and POST
parameters (ie a POST request to http://server.com/endpoint/?foo=bar
with the POST variable "foo" as well).  I was concerned with browser
support in doing this, but was assured that it wouldn't actually be a
problem.  So now it seems we're back to the drawing board around this...

I agree with Brad that the right solution is defining how the OP tells
the RP that there is more data and provides a key to access it.  That
fits with the description of OpenID being an interoperable framework of
small specifications.

With that said, I do agree that just throwing all the data into POST
allows for simpler implementations at the cost of some browser trickery
and potentially poor user experiences.

In the spec itself, we also talk about how OPs should not rely on
scripting for various reasons.
http://openid.net/pipermail/specs/2006-November/000904.html

Can anyone provide a reason, beyond the 2K limit since there are other
ways to address that problem, why POST only is the superior solution?

--David

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Brad Fitzpatrick
Sent: Saturday, November 18, 2006 4:31 PM
To: John Kemp
Cc: specs at openid.net
Subject: Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID
withREST/SOAP)

On Sat, 18 Nov 2006, John Kemp wrote:

> Dick Hardt wrote:
> >>
> >> But why deprecate support for redirects? I'd (still) like to see 
> >> OpenID implementations that do support browsers without JS turned
on .
> >
> >
> > As stated a number of times, because the payload is not big enough 
> > with GET redirects. It is with JS POST redirects.

The alternative is to say OpenID can't pass big messages in core
protocol messages and there could be an extension for how to do it
out-of-band when needed.

> > OpenID 1.1 did not have a large payload. We expect the payloads to 
> > be much larger with OpenID 2.0.
>
> I guess the payload size will vary according to the RP and IdP 
> implementations, no?

Exactly.  In the common case, they'll be small, easily within a GET
request.  But we're throwing out the common case and designing for the
hypothetical cases.  *sigh*

> > We will see if the JS requirement is an issue. I do not think it is 
> > given what I know now.
>
> Well, admittedly, if no-one except me thinks that redirects should be 
> supported in OpenID 2.0, then I certainly expect to lose that argument

> ;)

I hate making GET deprecated.  I don't mind POST also existing (well, I
do mind, but not enough to fight it), but I definitely think GET needs
to stay as a equally recommended method.  I hate the idea of JavaScript
being necessary for a simple auth request.

- Brad

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs