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

[Ben Laurie]

On Mon, Jul 6, 2009 at 6:54 AM, Adam Barth<cap-talk at adambarth.com> wrote:
> On Sun, Jul 5, 2009 at 7:55 PM, Karp, Alan H<alan.karp at hp.com> wrote:
>> Thanks for the clarification.  If I understand correctly, the other spec makes it possible to reject a request from a third party that would be accepted from the user.  I understand the motivation for that case because the user has a credential, such as a session key, that the third party does not.
>
> Unless you can whistle to your modem, users don't make requests.
> Software makes requests (perhaps on behalf of users, but perhaps not).
>
>> CORS makes it possible to accept a request from a third party that would be rejected if it came from the user.
>
> I'm not sure this is a helpful way of thinking about the situation.
>
>> I'm having trouble understanding the value since there is no other credential.  The only authentication is the Origin header, which means forgery is trivial.
>
> How can Bob's Finance forge this header from the user's browser?

With a plugin, or a custom browser.

But I think Alan's point was that the user could forge the header.

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

And neither Google nor Acme Finance care if users forge the header and
thus get access themselves?

Its pretty clear (I think) that this problem is just plain insoluble
if the aim is to go via the (untrusted) browser, so the main thing is
to make it explicit, I guess.