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

Johannes Ernst jernst+openid.net at netmesh.us
Mon Nov 20 04:09:37 UTC 2006


The fundamental error, in my view, is to say "we can only  
authenticate POST'd operations". Of course, sometimes one does want  
to authenticate POST operations, such as in order to POST >2KB  
identity information to some relying party. But in many other cases,  
we want to GET information or DELETE information or PUT information  
or OPTIONS information etc. In my view, there is no need whatsoever  
to limit OpenID Auth to the POST operation -- it disallows many valid  
use cases, and I'm against that.


On Nov 19, 2006, at 20:02, 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




More information about the specs mailing list