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

[Adam Barth]

On Mon, Jul 6, 2009 at 1:15 PM, Rob Meijer<capibara at xs4all.nl> wrote:
> 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.

Bob just gets token (a) from acme.com and can use the token to access
finance.google.com from the user's browser as long as he keeps his
session with Acme alive (which seems quite easy).  I don't see how the
revocation token helps with security at all.

> 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?

I don't understand these complicated words.  Can we try to get an
example system that works first before trying to generalize the
properties that all such systems must have?

Adam