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

[Dick Hardt]

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
>
>