[access-control] comments on Working Draft 1 October 2007

I have some questions and suggestions regarding Working Draft 1  
"Enabling Read Access for Web Resources" [1], as follows:

Questions
1. Should it be possible to use an HTTP HEAD method to obtain HTTP  
access control headers without needing to obtain the entire  
representation. This might be more efficient in some cases. This  
could address a potential security risk associated with retrieving an  
entire resource when its use may not be allowed.

2. Has the WG considered having the server process XML document  
access control PI directives and then providing that information as  
HTTP headers, avoiding the need for client processing of the XML  
document? Could this be a simplification for clients and allow use of  
HTTP HEAD consistently?

3. Why is use of an XML Processor required to process the Processing  
Instructions in the prolog? Couldn't simple text processing also be  
used?

4. Does the order of null and "*"  steps matter (in 2.2.3 URI  
matching), #3.

Suggestions

1. Try to avoid replication of algorithm steps in section 2.2.2  for  
HTTP access control header vs XML access control processing  
instructions. Instead define once and reference second time, to avoid  
potential divergence. Parameterized algorithm. Example is #3 and #6  
in header/PI algorithm respectively.

2. Clarify the algorithm steps in 2.2.2
a. Use numbers for outer steps, letters for inner.
b. The phrase "the overall set of steps" is ambiguous. Presumably it  
means the outer list.
c. Be explicit as to what happens when a match is found (e.g. in #2/#1.)

It might be simpler and clearer to have a statement like
"If a URI deny match occurs that is not in the deny-exclude list then  
deny otherwise if a URI allow-match occurs that is not excluded then  
allow. Otherwise deny."

3. Add to security considerations

"Integrity protection of the access control policy statements may be  
required. This could be achieved by use of SSL/TLS for example."

4. It might be helpful to add an additional clarifying paragraph to  
the end of the introduction, section 1

" Access control policies are defined in conjunction with the  
resources that might be obtained and are expected to be enforced by  
the client that retrieves and processes those pages. Thus the client  
is trusted and acts as a policy enforcement point. "

5. Editorial in 1.2, Security considerations

2nd paragraph, s/could not accessed/could not be accessed/
first bullet s/exists/resource exists/

6. In 2.2.1 where it states that http://example.org is not equivalent  
to http://example.org:80 it might be worth stating why. Is is that a  
server can configure a different default port?

regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/TR/access-control/

Received on Friday, 2 November 2007 20:10:00 UTC