W3C home > Mailing lists > Public > public-appformats@w3.org > November 2007

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

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
Message-ID: <op.t1sixmea64w2qv@annevk-t60.oslo.opera.com>

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  

> 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."


> 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/

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:  

Anne van Kesteren
Received on Wednesday, 14 November 2007 16:33:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:08 UTC