Re: Accountability in AC4CSR

Close, Tyler J. wrote:
> Hi Jonas,
> 
> Please try re-reading my first post in this thread. I tried to explain this issue in that message. I'll put some more text below to try for further clarification.

I might have misunderstood your initial mail, it sounded to me like you 
were depending on a dishonest browser, but maybe that wasn't the case?

> Jonas Sicking wrote:
>> Close, Tyler J. wrote:
>>  > Since the cross-domain request is labeled by the browser with the
>>  > Referer-Root of Site A, it is tempting to say Site A should be held
>>  > accountable. Unfortunately, this is not secure since Site B cannot
>>  > know for sure that this labeling was done by an honest
>> browser. Using
>>  > another tool, the user could send a request to Site B
>> labeled with a
>>  > Referer-Root for Site A, in effect attempting to blame
>> Site A for the
>>  > request to Site B. So Site B is left in the position of
>> not being able
>>  > to hold either the user or Site A accountable for the request.
>>
>> What accountability mechanism is used today if the browser
>> isn't honest?
>> It seems to me like you are hosed then no matter what in the scenario.
> 
> Today, the user is assumed to have sole possesion of their password and the power to determine how it is used. This WG is relaxing this constraint to additionally give certain approved sites the ability to wield the user's password. The problem is that in this new world we don't know who to hold accountable for any given request: the user or the site named by the Referer-Root header.

Ah, well, I'd say it's the Referer-Root site acting as an agent for the 
user. So if you trust the Referer-Root site then you can hold the user 
accountable. But if you don't trust the Referer-Root site, such as if 
you've never heard of it, then you should hold the Referer-Root site 
accountable.

Does that answer your question?

/ Jonas

Received on Thursday, 7 February 2008 00:58:59 UTC