W3C home > Mailing lists > Public > public-wsc-wg@w3.org > December 2007

RE: Comments on: Access Control for Cross-site Requests

From: Doyle, Bill <wdoyle@mitre.org>
Date: Tue, 11 Dec 2007 15:28:14 -0500
Message-ID: <518C60F36D5DBC489E91563736BA4B5801CB9D28@IMCSRV5.MITRE.ORG>
To: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>, <tyler.close@hp.com>
Cc: <public-wsc-wg@w3.org>
This is what i came up with, in reading the protocol I could not
determine a servers right to limit use of the proposed extensions.

The Access Control for cross-site requests extension appears to have a
major impact to a web servers Information Assurance (IA) model and may
have profound effects on security agreements in place that govern use
of the web server. If a client becomes a Policy Decision Point for a
server, the server must rely on the clients IA capabilities and
robustness of IA controls in place for the client to ensure that the
server and any applications hosted on the server are not compromised.


Given the considerations noted above, the proposed Access Control for
cross-site requests  must take into consideration the following


1.	The cross-site scripting protocol must include strong
cryptographic mechanisms to ensure that the server can restrict use of
the capabilities to authenticated and authorized clients.
2.	The protocol must provide the ability for a server to support
fine grained access control. e.g. a server should be able to limit
write access to a specific client noted in item 1.
3.	Protocol must be able to restrict inheritance of a clients
access control rights by other clients. 
4.	Resources must be protected until access is granted; the
security consideration that resources are not revealed is not strong



	From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Mary Ellen Zurko
	Sent: Wednesday, December 05, 2007 2:39 PM
	To: tyler.close@hp.com
	Cc: public-wsc-wg@w3.org
	Subject: Re: Comments on: Access Control for Cross-site

	Thanks Tyler. When you're ready you (and Bill, and Hal) should
send your (their) comments directly to them at
From: 	"Close, Tyler J." <tyler.close@hp.com> 
To: 	"public-wsc-wg@w3.org" <public-wsc-wg@w3.org> 
Date: 	12/05/2007 02:04 PM 
Subject: 	Comments on: Access Control for Cross-site Requests


	I've got one major comment on this proposal that I think is
sufficient to send it back to the drawing board. I'll delay making more
detailed comments about the proposal until I find out the answer to the
major comment.
	A significant portion of the proposal is devoted to specifying
a policy language for determining whether or not a page from a
particular "root URI" should be allowed to issue a cross-domain request
to a particular server. I think the problem can be solved without the
server and the client software agreeing on such a policy language. For
example, rather than have the server specify the rules for cross-domain
requests and have the client enforce these rules, the client should
simply send the request information to the server and have the server
enforce its own rules. I see no advantage to placing this logic in the
client, as opposed to the server. Placing the logic in the client
introduces significant complexity which creates many opportunities for
implementation bugs, specification ambiguity and misunderstanding by
web application developers, while possibly limiting the kinds of
policies a server can enforce.
	There is also a significant factual error in the document's
	However, it is not possible to exchange the contents of
resources or manipulate resources "cross-domain".
	It *is* possible to manipulate resources "cross-domain". An
HTML page can contain a FORM which submits an HTTP request
"cross-domain". Submission of this request can be automated using
Javascript. The Same Origin Policy only prevents the HTML page from
accessing the response to the issued request. Manipulation is allowed.
Only responses are protected, not requests.
	[1] "Access Control for Cross-site Requests"
<http://www.w3.org/TR/access-control/> >
Received on Tuesday, 11 December 2007 20:29:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:19 UTC