[cap-talk] Fwd: [cors] TAG request concerning CORS &Next Step(s)

[Dave Chizmadia - Gmail]

On Friday, June 26, 2009 at 04:36 -0400, Toby Murray wrote:
> On Fri, 2009-06-26 at 00:52 -0700, Adam Barth wrote:
> > Here's what I said:
> > 
> > [[
> > How exactly do you envision secret tokens working?  Suppose Google
> > Finance wants to let Acme Finance XHR for stock ticker information.
> > How does Acme Finance get the secret tokens?  Presumably Acme has to
> > use a fresh token for each request so that Bob's Finance can't just
> > grab Acme's token from their home page.  Now, for each request, Acme
> > Finance has to contact Google Finance on the backend and 
> get a token.
> > Sounds like a pain.
> > ]]
> > 
> > What I meant by "sounds like a pain" is in this strawman 
> design, ACME
> > has to make a network request from the browser to acme.com and from
> > acme.com to finance.google.com for each request it wants to 
> make from
> > the client to finance.google.com.  That seems counter productive
> > because ACME might as well just proxy the stock ticker data at that
> > point.
> 
> Right. So proxying (which was raised as one potential solution in this
> thread) is out. As David Wagner pointed out (amongst others) all
> alternative approaches require the cooperation of finance.google.com .
> Specifically, google must implement an API that allows its direct
> customers (like acme) to export google's services to acme's 
> users whilst
> not requiring acme to proxy.
> 
> 
> > It's entirely possible there's a better design that doesn't 
> involve as
> > many requests.  I was just asking what that design is.
> 
> A number of emerged in this thread. (I'll try not to 
> misrepresent them.)
> 
> One proposal (I think independently from Ihab and David Chizmadia)
> was that the acme webserver makes a single request to google at 
> the start of each user's session with acme to obtain a token for 
> that user. This requires that acme supports some notion of user 
> sessions, however. I expect your example doesn't want to make this 
> assumption from other things you've said in this thread. 
> 
> Another proposal (from Sandro Magi) was for finance.google.com to
> support some kind of API in which a secret token issued to each
> visitor to acme is then passed to finance.google.com (via an XHR 
> in the user's browser). In response google issues each of acme's 
> visitors a token (which perhaps expires after a certain amount of 
> time or is otherwise attenuted in some way) that the user can then 
> use to make XHR requests to google to fetch stock prices.
> 
> David Wagner also suggested negotiating a shared key between acme 
> and google. Acme uses this shared key to construct tokens that can 
> be recognised and authenticated by Google. 

Another approach - which probably has the least impact on current
web design patterns and can be easily implemented by a front-end
service - is to use time- or use-limited promises to the data of
interest (in Adam's example, google finance stock data). In this 
case, Acme would bootstrap things by using a b2b API to request
a promise (reified as an unguessable URL) to the stock data. To
simplify the overall protocol, Acme should provide a callback so 
that Google can send a new promise when the old one expires. The
promise could either have a set number of hits to which it will 
respond or a specific time beyond which it will not respond. Acme
inserts the promise into the stockTicker JS applet, which is then
downloaded by Acme site visitors. When the promise expires, it 
returns an appropriate (404?) error to the browser, which provokes
a reload of the of the stockTicker with an updated raw data URL. 

If I understand the use case correctly, this should be easier
for the browser - which wouldn't have to maintain state about 
the Origin of authority - and no more administrative hassle on
the supplier server (e.g., Google), since maintenance of the
identity and authorizations of the consumer server (e.g., Acme) 
will be necessary in either case.

It would be very interesting to design a supplier server front-
end and associated consumer server and browser JS libraries to 
determine the practicality and usability of this approach (lets 
call it LAGER - Least Authority General Extension to ReST ;-) 
as compared to the CORS approach.

-DMC