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

[Dave Chizmadia - Gmail]

I must be missing something, since this seems to be one
of the easier use cases for capabilities to satisfy...

To summarize:
  * flightsim.com has a chargeback mechanism (account) with
    worldmap.com;
  * worldmap.com provides APIs to create and manage objects 
    in a 3-D space;
  * flightsim.com uses the worldmap.com APIs to provide the 
    world in which its airplanes exist and interact with 
    each other;
  * an airplane user is essentially "subletting" flightsim.com 
    access to the worldmap.com APIs;
  * the goal is to ensure that worldmap.com can correctly 
    charge flightsim.com for the actions of its users and 
    flightsim.com can in turn correctly charge its users for 
    the use of worldmap.com APIs;
  * we want to minimize network traffic between flightsim.com
    and worldmap.com so that airplane users pay the performance 
    and networking costs.

I see this as easy because the APIs will be reified as a 
loadable javascript module. So the obvious solution is that 
each time an airplane user loads the airplane module (which 
itself loads the worldmap API module), flightsim.com first
uses a worldmap.com b2b API to request that worldmap create 
an API module instance and return the webkey to that module.
Flightsim then inserts that webkey into the load command for
the worldmap API module. 

When worldmap creates the unique module instance, it generates
new webkeys for each method of the API so it can track which 
module instance should be "charged" for the use. As a value-
add to flightsim, it could even accept a string in the b2b API
that would allow flightsim to associate its user with the 
actions. When the user's browser loads and executes the airplane 
module, it then loads those webkeys directly from worldmap.com.

So please help me understand what I'm missing - since this 
doesn't seem like a particularly hard solutions and seems to
have better accountability and performance than any "ACL"-
like solution would have...

-DMC


> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Toby Murray
> Sent: Thursday, June 25, 2009 2:10 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Fwd: [cors] TAG request concerning 
> CORS &Next Step(s)
> 
> 
> On Thu, 2009-06-25 at 10:54 -0700, ihab.awad at gmail.com wrote:
> > And to further refine the parameters --
> > 
> > On Thu, Jun 25, 2009 at 10:46 AM, <ihab.awad at gmail.com> wrote:
> > > Excuse me if this has been covered elsewhere but: concretely, what
> > > would be the actual CORS architecture for achieving this scenario?
> > 
> > The CORS solution I seek to understand would be as follows:
> > 
> > - The implementation of the "airplane objects" is now 
> embedded in the
> > end-users' browser, so that, when the airplanes move around, the
> > airplane object makes a direct call to worldmap.com to modify its
> > current position and query for other airplanes in its vicinity.
> > 
> > - The solution does not require worldmap.com to issue more accounts
> > than with the capability / webkey / ... solution. There is just one
> > account on worldmap.com, issued to flightsim.com. Specifically, we
> > *cannot* assume that worldmap.com (perhaps at the request of
> > flightsim.com) mints a new account on *their* site for each user of
> > flightsim.com.
> 
> worldmap.com keeps an ACL whitelisting which customers can 
> make request
> on it. This ACL includes flightsim.com.
> 
> The CORS proposal (from what I understand, which could well be bugger
> all) has the user's browser, when it makes requests of worldmap.com on
> behalf of flightsim.com, issue an "Origin" header that says 
> something to
> the effect that "the origin of this request is flightsim.com".
> worldmap.com checks the origin against its ACL. Voila.
> 
> Cheers
> 
> Toby
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>