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

[Rob Meijer]

On Mon, July 6, 2009 19:51, Adam Barth wrote:
> On Mon, Jul 6, 2009 at 10:26 AM, Rob Meijer<capibara at xs4all.nl> wrote:
>> On Mon, July 6, 2009 07:54, Adam Barth wrote:
>>>> I can't imagine Acme Finance would be happy about paying for a service
>>>> with such a flaw.  Maybe the problem is that I don't understand how
>>>> the
>>>> Origin header gets used.
>>>
>>> The service lets Acme Finance contact Google Finance directly from the
>>> user's browser (i.e., without proxying via acme.com).  This is
>>> valuable to Acme.
>>
>> Wouldn't it be much simpler for this scenario if Google Finance would
>> provide an API with what Acme Finance could create and manage proxies at
>> google.com to delegate to individual users?
>
> How would this work without leaking Acme Finance cookies / passwords
> to Google?  In other words, how could we secure such a system against
> a malicious data provider?

How I interpret your scenario is that Acme has some authority to Google
that it wants to partially delegate to some known user's browser.
With Acme implementing an attenuating or decomposing proxy that takes care
of both attenuation, decomposition and revocation, there is the issue of
Acme needing to stay in the loop all the time. The alternative is to let
the data provider provide mechanisms for decomposition, attenuation and
revocation.

A little walk true:

1) User logs in to Acme using her browser.
2) Acme, using the Acme credentials with Google Finance, uses the API to
   create a proxy object bestowed with a SUBSET of the authority belonging
   with the Acme account at google finance.
3) Google Finance returns two handles (for example a url with a spare key
   in it) to the newly created proxy:
   a) One for delegation to the browser.
   b) One for REVOCATION of the first one.
4) Acme delegates the A handle it received from Google Finance to the
   browser.
5) The browser can use the access to the proxy object at Google Finance with
   Acme out of the loop.
6) Ones the session ends at Acme (for example the session expires, the user
   logs in from an other location, the user account is suspended etc), Acme
   invokes the revocation handle, and the proxy handle becomes useless.


There are basically 3 components to the generic solution:

1) Decomposition of authority.
2) Delegation of decomposed authority.
3) Revocation of delegated decomposed authority.

The fact that your prerequisite is that Acme should get out of the loop,
the most logical would seem that Google Finance provide mechanisms for
decomposition and delegation to the browser, while allowing revocation to
remain in control of Acme.

Does this decomposition make any sense, or am I misinterpreting the
scenario you are trying to solve?

Rob