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