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

[Matt Pelletier]

On Nov 18, 2006, at 7:31 PM, Brad Fitzpatrick wrote:

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

I'd just like to re-emphasize my thoughts about this aspect of the  
spec. Once this spec is ratified it will be followed for an  
undetermined amount of time, to be implemented by people with  
constraints that we cannot foresee (</obvious>). I don't see anything  
detrimental to the efficacy or capability of the protocol or of the  
clarity of its implementation requirements by keeping the GET  
redirects in (whether as an equal or fallback method to form  
redirects). Even if form redirects worked with high-end mobile  
handset browsers, I'd wager there will be uses that have nothing to  
do with a 'browser' as we refer to it. What about raw HTTP clients  
that would sit behind a custom application? While it would be  
overkill to allow a dozen ways to implement a feature, it seems  
shortsighted to allow only one (one that actually replaces the  
existing, proven method, mind you). I found OpenID's simplicity and  
leverage of HTTP (especially it's redirects) as its most appealing  
features. Even as it will enjoy much broader capabilities in this 2.0  
spec, I think it's important to maintain that simplicity.

My vote is to keep GET redirects in.

Matt

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

------------------
Matt Pelletier
http://www.eastmedia.com -- EastMedia
http://www.informit.com/title/0321483502 -- The Mongrel Book
http://identity.eastmedia.com -- OpenID, Identity 2.0