Accountability in AC4CSR

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

Received on Wednesday, 6 February 2008 22:06:46 UTC