One of the primary purposes of access control is correctly assigning 
accountability for actions. I think the current AC4CSR proposal creates subtle 
and perhaps unexpected consequences for an application's ability to correctly 
assign accountability.

On the Web, it is common for an application to be designed such that the user 
whose authentication cookie was used in an operation is held accountable for 
that operation. For example, I am accountable for deleting email from my 
web-based email account. The basis for assigning this accountability is that my 
password is private to me, so the operation must have been submitted by me, or 
an agent I have given my password to.

Since the current AC4CSR proposal requires that the user's cookies be sent in a 
cross-domain request, this basis for assigning accountability no longer holds. 
A web page from Site A which issues a cross-domain request to Site B could do 
so without the knowledge of the user, so the user cannot reasonably be held 
accountable for the effects of the request. 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 mechanism is the WG recommending for assigning accountability for a 
cross-domain request? It seems some mechanism must be recommended, since the WG 
has eliminated the status quo approach.

--Tyler

Reply via email to