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. > For what it's worth, we went through a similar discussion when we were trying to define a version of OAuth for "unregistered" consumers, and are proposing the following there ( http://step2.googlecode.com/svn/spec/unregistered_oauth/latest/oauth-unregistered.html ): - use POST by default, to reduce the risk posed by open redirectors (which tend to not redirect on a POST) - when using GET (which can be requested by the consumer), put the sensitive payload into the fragment. This has the performance benefit Luke mentions if the consumer is Javascript, _plus_ also helps with open redirectors - the sensitive payload doesn't hit the servers and most browsers drop it across 302s. Dirk. > 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 > >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
