On Thu, Mar 26, 2009 at 9:46 PM, Luke Shepard <lshep...@facebook.com> wrote:
> This thread has been really useful – thanks for the responses everyone. I > have a few inline responses to a few different emails, bear with me while I > try to unify the thread. > > From Breno: > > The very legitimate question here is whether it is acceptable for the > OpenID spec to define that the query > > can be encoded in the fragment if a fragment is present in the return_to > URL. If the spec were to say it is > > valid, then there is no incorrect behavior (as no other spec is otherwise > violated). > > Yup, great point. We can just say that it is valid (as Google and Yahoo > have implemented it today) thus blessing this as a potential optimization > going forward. > > From Allen: > > Given that this fragment technique is intended to improve the user > experience, > > especially in the context of a popup window, I think that we may be able > to > > document the correct behavior this in the forthcoming UI Extension. > > After thinking a bit more on this, I realized that while performance of the > checkid_setup call in the popup is important, it’s a one-time cost so not > that big of a deal. > > A much bigger issue is the performance of checkid_immediate in an iframe. > For Connect, we do the equivalent of that on every single page. For OpenID, > I can see a case where a relying party would run a checkid_immediate on > every page (to make sure the user was still logged in). In fact, a relying > party might want to check multiple OpenID providers on a page load – maybe > even dozens or hundreds, potentially. If they did that, then the performance > of each call would definitely be a much bigger issue, and this HTTP load > would become more important. > > From James: > > Disallowing post responses limits the use of the more verbose > > extensions (e.g. attribute exchange). While this might be acceptable > > for Luke's particular use case, it might leave it unsolved for others. > > The POST response is a good point and clearly a valid use case, and I think > it’s supported no matter what we decide to do. It’s possible to build a > receiver that handles POST params if they are present, but otherwise serves > up the correct cache headers and Javascript to handle the GET. That would > provide a performance boost in the common case, while still being fully > compatible with the spec. > I would add that, in the case of checkid_immediate, it is not advisable to have many extensions. Each request to release an attribute increases the odds that the user will need to be prompted to approve the request, and therefore decreases the chance of success of a checkid_immediate request. As Luke pointed out, checkid_immediate stands to gain most from the latency improvements. > > > From Martin: > > To be honest, I'd be surprised if POST requests from OP to RP worked > > interoperably today, but the trick of using the # on the end of the > > return_to URL to signal to a supporting OP "I'm trying to do this > > completely client-side, so don't do a POST request" works here too. > > Maybe having the fragment is a clue, but I’d prefer an even more explicit > clue- like what if the RP could say “don’t send POST requests back, just > send no more than X chars in the GET no matter what”. Then the OP could just > drop data if it went over the limit ... or something. > > > > On 3/25/09 9:26 PM, "James Henstridge" <ja...@jamesh.id.au> wrote: > > On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins <m...@degeneration.co.uk> > wrote: > > James Henstridge wrote: > >> > >> On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard <lshep...@facebook.com> > >> wrote: > >>> > >>> One crude way to do it would be to have the caller specify that they > want > >>> the return_to args simply appended instead of integrated into the URL- > >>> perhaps an argument like openid.append_return_to_params=true. But that > >>> sounds hackish and I’d love to hear feedback on a better way to do > this. > >> > >> How would this interact with OpenID providers that respond via a POST > >> request instead of a GET? This is something they are permitted to do > >> according to the spec, and may decide to do so even if the > >> authentication request was started with a GET if the response is large > >> enough. > >> > > > > This is a good point, but it seems like again it can be worked around by > > making openid_reciever.html accept POST requests. > > > > Unlike the query string, this can't be done completely client side, but > it > > ought to be reasonably simple to set up some kind of rewriterule or other > > indirection trick to make POST requests to openid_reciever.html actually > get > > served by a non-static endpoint. > > Any intermediate caches would also drop their cached versions when > they see a POST request too (assuming they follow the standards), but > I suppose it'd still be a win if the POST requests are infrequent. > > This is starting to become a lot more complicated than the "simple > static return_to page" from the initial proposal though. > > > > To be honest, I'd be surprised if POST requests from OP to RP worked > > interoperably today, but the trick of using the # on the end of the > > return_to URL to signal to a supporting OP "I'm trying to do this > completely > > client-side, so don't do a POST request" works here too. > > Disallowing post responses limits the use of the more verbose > extensions (e.g. attribute exchange). While this might be acceptable > for Luke's particular use case, it might leave it unsolved for others. > It might be worth going back to basics and considering whether there > are other solutions. > > The stated aim was to provide the best user experience possible for > running an OpenID authentication request through a pop up window and > then communicating the results back to the main window. > > Luke's proposal is one possible solution, but I wouldn't want to > impose limitations on the specification if there is an alternative > that also solves the problem. > > James. > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
