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

[Recordon, David]

Dick, the spec as it stands does not allow the use of GET, rather only
allows the use of POST for transmitting messages.  Whether or not it
goes against W3C design guidelines, it is what is deployed today and
being used with no problems.  I fully understand the benefit of using
POST, in terms of the ease to piggyback additional data, but don't want
to be writing a spec where real world experience will cause it to not be
used when we can avoid that problem upfront. :-\

--David

-----Original Message-----
From: Dick Hardt [mailto:dick at sxip.com] 
Sent: Sunday, November 19, 2006 10:52 PM
To: Recordon, David
Cc: Brad Fitzpatrick; John Kemp; specs at openid.net
Subject: Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID
withREST/SOAP)

Here is my summary:

1) Trying to guess what the user-agent can do I think is a *really* bad
idea.
2) A GET will work if the data is less then 2K, but using it goes
contrary to the W3C design guidelines [1]
3) A POST will always work, but the user experience will be clunky for
browsers without JS support, and I agree it is somewhat of a hack.

Since both a GET and a POST are allowed, although the preference is for
a POST, I'm don't think we need to change anything. Real world
experience will dictate if the use of JS with the POST is an issue.

I vote let's move on.

-- Dick

[1] http://www.w3.org/DesignIssues/Axioms.html#state

On 19-Nov-06, at 8:02 PM, Recordon, David wrote:

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