Note that de facto standards such as OAuth address this issue to some
extent. Does AC need to address it as well?
-John
On Feb 6, 2008, at 2:05 PM, "Close, Tyler J." <[EMAIL PROTECTED]>
wrote:
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
