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

RE: comments on access control for cross-site requests - WSC member

From: Doyle, Bill <wdoyle@mitre.org>
Date: Tue, 18 Dec 2007 09:37:30 -0500
Message-ID: <518C60F36D5DBC489E91563736BA4B5801CBA296@IMCSRV5.MITRE.ORG>
To: "Jonas Sicking" <jonas@sicking.cc>, "WAF WG (public)" <public-appformats@w3.org>

Hi Jonas thank you for the response, 

Not sure how the web server protects itself - "site should be protected
from any other requests until it grants access"

I understand that the 3rd party can restrict access. The requirement is
for the web server to have a mechanism (i.e. configuration setting or
other type of control) that allows or disallows access control for
cross-site requests and the web server has the ability to restrict 3rd
party access to settings that are controlled by the web server.

Issue is that the web server owner looses Information Assurance (IA)
control, this is an issue for my customers. IA control cannot be handed
over to a 3rd party. For my customers, the web server owners need to
manage the IA settings.

Regards
Bill Doyle
wdoyle@mitre.org



 
-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: Tuesday, December 18, 2007 1:34 AM
To: Doyle, Bill; WAF WG (public)
Subject: Re: comments on access control for cross-site requests - WSC
member

Doyle, Bill wrote:
> 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.

The third party site can require that all communication between the 
third party server and the browser is done using https by simply
denying 
all access requests done through any other means.

The third party site can also require that all communication between
the 
browser and the requesting site is done over https by only
white-listing 
https servers.

Does this satisfy the request?

Additionally, it is possible to extend this further in the future by 
adding additional attributes to require even stronger protection. This 
is done in a forwards compatible manner by saying that a current 
implementation that sees any unrecognized attributes must deny access.

> 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.

Any type of access, including write access can be limited according to 
the rules described above.

> 3.        Protocol must be able to restrict inheritance of a clients 
> access control rights by other clients.

I don't quite understand this question.

> 4.        Resources must be protected until access is granted; the 
> security consideration that resources are not revealed is not strong
enough.

The only requests that can be made without explicit authorization are 
GET requests. These requests are already possible today. The site
should 
be protected from any other requests until it grants access.

Best Regards,
Jonas Sicking
Received on Tuesday, 18 December 2007 14:37:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:24 GMT