On Nov 17, 2006, at 1:24 AM, Dick Hardt wrote: > Hi John > > So that a message can be more then 2K of data. >
Is it possible to update the language so 1) we don't deprecate HTTP redirects and 2) the form redirect method is described as the preferred/recommended approach, but is not required? You could even stress that HTTP redirects should only be used when the HTTP client's capabilities/limitations would adversely affect the application behavior (or user experience, whatever language is more appropriate for the spec) if form redirects were attempted. I agree with John on the basis that not all HTTP clients will have JS functionality, whether disabled or unavailable, and whether we can imagine what those clients would be or not (blackberry, mobile phone, iPod, Nike running shoe, car keys). The choice to deprecate HTTP redirects involves some assumptions that seem too broad: 1) Payloads will be > 2K often enough that there is little value in supporting more than one way to redirect 2) JS will be available to automate the user experience, or at least that automating the user experience isn't that important. 3) Deprecating functionality already built into the key spec (HTTP), that is already in use in OpenID 1.x, is preferred to supporting it, even though form redirects will involve more moving parts and specs (ECMA / JS) to maintain the same basic user experience. What do you think? Dick, do you have a list of the browsers you tested against? Matt > -- Dick > > On 16-Nov-06, at 10:17 PM, John Kemp wrote: > >> Hi Dick, >> >> My point is that I don't think requiring JS for a reasonable user >> experience is a good idea when considering the variety of browsers >> that >> are deployed today, and I don't understand why it's necessary. >> >> I am interested to know why one would decide to restrict the protocol >> this way. Can you perhaps illuminate the reasoning? >> >> Cheers, >> >> - John >> >> Dick Hardt wrote: >>> Hi John >>> >>> Would you provide examples of those browsers? Testing we did 2 years >>> again indicated the JS redirect worked on all the platforms we >>> tested on. >>> >>> -- Dick >>> >>> On 16-Nov-06, at 11:35 AM, John Kemp wrote: >>> >>>> Hi, >>>> >>>> Sorry I'm just reading this, but I just wanted to put in a point >>>> very >>>> much in favour of NOT deprecating support for HTTP redirects in >>>> OpenID >>>> 2.0. >>>> >>>> I'll note that requiring the user to press a 'submit' button to >>>> "push" >>>> seems like a dodgy UI strategy. So then you require JavaScript to >>>> produce a reasonable user experience. >>>> >>>> Well, as a representative from the mobile community, I'll tell >>>> you that >>>> there are quite a few browsers out there (on deployed mobile >>>> phones) >>>> that still don't support JS in any useful way! >>>> >>>> So with OpenID 2.0, you may now be requiring many users to click >>>> a form >>>> submit. >>>> >>>> Regards, >>>> >>>> - John >>>> >>>> Johannes Ernst wrote: >>>>> Well, as I've said before, I strongly believe that tying >>>>> authentication >>>>> to one particular HTTP verb is a bad idea, and unnecessary. >>>>> >>>>> I also believe that involving JavaScript in what is >>>>> fundamentally an >>>>> HTTP-level kind of protocol is a hack. It very likely is either >>>>> unnecessary or points to a flaw in the conceptual model of the >>>>> protocol, >>>>> or both. >>>>> >>>>> The same may be true about having different protocols for thin- >>>>> client >>>>> and rich-client. >>>>> >>>>> Having said that, I am not making this point more strongly than >>>>> I have >>>>> because I don't think these issues are fatal and I don't want to >>>>> raise >>>>> more issues that delay OpenID 2.0 auth further. So I will log >>>>> this as a >>>>> bug against auth 2.0 as soon as it is published (and as soon as >>>>> there is >>>>> a place where to file bugs against the spec ;-)) but will bite >>>>> my tongue >>>>> in the meantime. >>>>> >>>>> >>>>> On Nov 12, 2006, at 20:29, Dick Hardt wrote: >>>>> >>>>>> >>>>>> On 12-Nov-06, at 8:19 PM, Adam Nelson wrote: >>>>>> >>>>>>> Hi Dick: >>>>>>> >>>>>>>> I think REST support is a really useful feature, and have >>>>>>>> described >>>>>>>> how that might happen in the past, but right now we are pretty >>>>>>>> focussed on getting browser based auth finalized, and I think >>>>>>>> the >>>>>>>> mechanisms for rich clients will be related, but slightly >>>>>>>> different. >>>>>>> >>>>>>> That all makes sense, thanks. Is that to say that rich client >>>>>>> support >>>>>>> isn't a goal of v2.0 of the spec, or just a goal subsequent to >>>>>>> the >>>>>>> conclusion of browser-based auth? >>>>>> >>>>>> Not a goal of OpenID Authentication 2.0 >>>>>> >>>>>> I think it would make sense to make it a separate document, and >>>>>> would >>>>>> value your involvement! >>>>>> >>>>>> -- Dick >>>>>> _______________________________________________ >>>>>> specs mailing list >>>>>> specs@openid.net >>>>>> http://openid.net/mailman/listinfo/specs >>>>> >>>>> >>>>> >>>>> Johannes Ernst >>>>> NetMesh Inc. >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> ----- >>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> ----- >>>>> >>>>> http://netmesh.info/jernst >>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> ----- >>>>> >>>>> _______________________________________________ >>>>> specs mailing list >>>>> specs@openid.net >>>>> http://openid.net/mailman/listinfo/specs >>>> >>>> _______________________________________________ >>>> specs mailing list >>>> specs@openid.net >>>> http://openid.net/mailman/listinfo/specs >>>> >>>> >>> >> >> > > _______________________________________________ > specs mailing list > specs@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 _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
