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/
