- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 14 Nov 2007 17:33:12 +0100
- To: "Frederick Hirsch" <frederick.hirsch@nokia.com>, public-appformats@w3.org
On Fri, 02 Nov 2007 21:09:04 +0100, Frederick Hirsch <frederick.hirsch@nokia.com> 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/>
Received on Wednesday, 14 November 2007 16:33:33 UTC