On Tue, Aug 3, 2010 at 9:59 AM, Oleg Gryb <oleg_g...@yahoo.com> wrote: >> Question: why are you implementing the user-agent flow? > > It's not helpful. Doesn't answer the qs.
The reason I asked is because I suspect you are trying to use the user-agent flow in a way very different from other people. It's important to choose the right tool for the right job. Given that you are writing lots of server-side code, you should probably be looking at the web server flow, not the user-agent flow. > Please provide an example of code that you would put to thirdparty.com and > that > would not break the use cases. Take a look at the facebook APIs, in particular the cross-domain communication schemes: http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication_Channel > Please also provide an example of response from > serviceprovider.com with an access token in it (wherever it is - as I > understand > you want to put it to the Location header, but probably I'm wrong). HTTP/1.1 302 Moved Temporarily Location: http://www.thirdparty.com/rpc_relay.html#access_token=12345 rpc_relay.html is highly cached in the browser, so instead of incurring hundreds of ms to fetch a file, the data lands in the third-party.com javascript in under a millisecond. > Is it a requirement/use case? Yes, it's a requirement. > Where is it written in the spec? Hopefully the spec will start adding more language around specific use cases to guide developers in picking which profiles they want to use. > What if > thirdparty.com generates that JavaScript on the server and returns in a > response? Would it be a violation of the protocol? It would not be a violation of the protocol. It would be inefficient. >> - do all of the above with as few client <-> server round trips as possible. > > When it comes to an authentication and communication protocols, security is > more > important than an extra round trip in my view, otherwise people would never > use > SSL, which is very inefficient from performance point of view. SSL inefficiency is largely mythical: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html. > Also, until I see > the code that I've asked for above, I won't understand how that "fragment" > solution will reduce the number of trips. HTH. If this hasn't been helpful, you want want to run up firebug and visit a web site like iGoogle. Watch the number of requests triggered in the browser, and watch how many are served from cache. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
