Re: Access control requirements

The existing point 3.5 I think is different from point 7.

Point 3.5 says that AC should be configureable on a resource by resource 
basis.
Point 7 is there to A) allow the server administrator to have the final 
word, and B) to give a quick way of disabling all cross site access in 
case AC has been wrongly configured for a set of resources, without 
having to shut down whole the server.

This clarification would be good to add. So something like

7.
It should be possible for the administrator of the server to disable 
cross site requests to any resource of the server. This should be easily 
doable on servers currently deployed using currently existing tools.

This will give the server administrator a quick way to disable cross 
site access to all resources on the server in case AC has been wrongly 
configured for some set of resources, without having to shut down whole 
the server.

It also gives the server administrator the final word in cross site 
access to all resources on the server.

/ Jonas

Arthur Barstow wrote:
> 
> Jonas, All,
> 
> Thanks for this input.
> 
> I think we should add all of them to section 3. of the UC+Reqs doc in 
> [1] and delete 3.3, 3.4 and 3.6 since they are covered your proposed 
> requirements #1, #2 and #3
> 
> Do you consider 3.5 covered by your #7 or some other requirement in your 
> proposal? If yes, then 3.5 should also be deleted.
> 
> Regards, Art Barstow
> ---
> 
> [1] <http://dev.w3.org/cvsweb/2006/waf/access-control/>
> 
> 
> On Jan 17, 2008, at 1:56 AM, ext Jonas Sicking wrote:
> 
>>
>> Here are the first round of requirements that I had. Looking forward 
>> to input.
>>
>> 1.
>> Must not require content authors or site maintainers to implement new or
>> additional security protections to preserve their existing level of
>> security protection. (Stolen from Brad Porter)
>>
>> 2.
>> Must be deployable to existing, commonly used, servers without 
>> requiring actions by the server administrator in a typical configuration.
>>
>> 3.
>> Must able to easily deploy support for cross site GET requests. This 
>> includes not having to use server side scripting (such as PHP, ASP, or 
>> CGI) in a typical server configuration.
>>
>> 4.
>> It should be possible to put the resource that is made available cross
>> site in its normal format on the server. It should be possible
>> to use normal development tools to interact with the resource directly
>> on the server. I.e. it should not be needed to repackage or reformat 
>> the resource just to make it possible to load from other servers.
>>
>> 5.
>> Content of any type should be possible to distribute. I.e. we should not
>> limit ourselves to content of a particular type.
>>
>> 6.
>> It should be possible to allow only specific servers, or sets of servers
>> to fetch the resource.
>>
>> 7.
>> It should be possible for the administrator of the server to disable
>> requests to any resource of the server. This should be easily doable on
>> servers currently deployed using currently existing tools.
>>
>> 8.
>> It should be possible to use resources on other servers using the same 
>> methods currently used to load resources. For example the following 
>> examples should be possible:
>>
>> <?xml-stylesheet type="text/xsl" href="http://other.server/file.xsl"?>
>>
>> <?xbl href="http://other.server/xbl.xml"?>
>>
>> xhr = new XMLHttpRequest;
>> xhr.open("GET", "http://other.server/data.text");
>> xhr.send();
>>
>> 9.
>> It should be possible to issue methods other than GET to the server, 
>> such as POST and DELETE.
>>
>> 10.
>> Should be possible to use normal authentication mechanisms on the 
>> server where the resource is located. I.e. on an IIS server where 
>> authentication and session management is generally done by the server 
>> before ASP pages execute this should be doable also for requests 
>> coming from other servers. Same thing applies to PHP on apache.
>>
>> / Jonas
>>
> 
>

Received on Thursday, 17 January 2008 19:22:20 UTC