On Fri, 02 Nov 2007 21:09:04 +0100, Frederick Hirsch
<[EMAIL PROTECTED]> wrote:
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.
That would not take into account <?access-control?> which would be a
problem.
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?
This has already failed with <meta>. I don't think we should try it again.
Especially since we want this to work more or less out of the box.
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?
As long as the simple text processing is identical to using an XML
Processor :-)
4. Does the order of null and "*" steps matter (in 2.2.3 URI matching),
#3.
Yes. If item is * and origin is "null" there is a match if matching for *
comes before "null". Otherwise there isn't.
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.
Actually, #2 and #6 are duplicates. Likewise for #3 and #7. Abstracted
these out now although I'm not sure if it becomes more readable now or not.
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."
Thanks, I'll look into this.
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."
Done.
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. "
Done.
5. Editorial in 1.2, Security considerations
2nd paragraph, s/could not accessed/could not be accessed/
first bullet s/exists/resource exists/
Couldn't find the first anymore. Probably reworded.
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?
Those are now equivalent to be on the safe side.
[1] http://www.w3.org/TR/access-control/
The latest draft is located here:
http://dev.w3.org/2006/waf/access-control/
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
