Re: Review of http://www.w3.org/TR/2007/WD-access-control-20071126/

On Mon, 10 Dec 2007 18:57:41 +0100, Williams, Stuart (HP Labs, Bristol)  
<skw@hp.com> wrote:
> I have an action from the TAG to review  
> http://www.w3.org/TR/2007/WD-access-control-20071126/
>
> Please regard the attached as personal comments. The TAG may  
> subsequently choose to support some, all or none of them.

Please regard the responses below as responses of the WAF WG. The WG may  
override my responses in subsequent discussion. (:-), though for real.)  
There are some questions included as well.


> I think that the early part of the document (mostly the introduction) is  
> written in a way that could be understood to suggest that resources  
> rather than their representations are being retrieved.
>
> [... about http://www.w3.org/TR/webarch ...]

I tried making it a more clear by talking about "Web page" and "image" and  
"data of a resource" which seems more in line with AWWW while remaining  
relatively easy to read and understandable to myself. :-) I hope that  
helps.


> The introduction would benefit from a little more explaination of what a  
> "cross-site" or "cross-domain" (pick juts one term) request is.

I added such an explanation. I also added it to the abstract.


> The opening sentence suggests that HTML img and script elements can  
> result in "cross-site" requests. That leaves me puzzled, unless what it  
> is intended to indicate is that img and script tags can result in the  
> retrieval of scripts (in the case of IMG I assume through further  
> references to scripts say from an SVG image) and the subsequent client  
> site execution of those scripts can give rise to "cross-site" requests.

The idea is that a Web page on domain A can use an image on domain B by  
means of <img>. The draft now clearly states this.


> Suggest pre-pending (or wteo):
>
> "A cross-site requests occurs when a retrieved resource representation  
> results in the loading of scripted client behaviours which, during  
> execution, request access resources in different domain from first  
> resource."

Cross-site requests in the draft are not restricted to scripting. For  
instance, attaching cross-site XBL bindings does not have to involve  
scripting.


> 2) Re: 4.3 <?access-control?> PI
>
> The 2nd para has not been fully updated to cover the addition of the  
> "method" pseudo attribute. eg. three->four and the value of a "method"  
> is *not* an "access item".

Actually, it is. It talks about three attributes of type X and one  
attribute of type Y.


> 3) Re: 5.1.1 Generic Cross-site Request Algorithm
>
>         Otherwise, let current request URI be the new URI and then
>         follow these set of steps:
>
>         ...
>
>         2. Otherwise, transparently follow the redirect while
>          observing the set of request rules.
>
> Suggest adding forward references to 5.1.2 and 5.1.3 on the phrase  
> 'request rules' - I was initially confused about what was being referred  
> to.

Would moving this down help? Similarly to your suggestion for the  
processing model algorithm?


> Substantive:
> ===========
> 1) Re: 5.1.3 Cross-site Non-Get Access Request - step 5 Otherwise Clause

Step 5 is not an otherwise clause. I'll assume that was a mistake.


> In the case of PUT, POST, DELETE the network operation has already taken  
> place - an "access control check" is a bit futile at this point, though  
> it may expose that the access policy has changed. Seems a bit odd to  
> force a fail in this situation, particularly if the network operation  
> has actually succeeded.

The access policy protects the information that is part of the response.  
The request itself is protected by the authorization request that is made  
before this one (or the authorization request cache).


> 2) Re Section 5 Processing Model
>
> This section is very hard to read: partly because the algorithm has a  
> very imperative style - and it would help to have an explicit statement  
> of the intention of the algorithm (more below); partly because of the  
> order in which elements of the algorithm are introduced eg. "5.2.1  
> Shared Algorithms" would be better understood if presented *after*  
> "5.2.2 Access Control Check Algorithm"; partly due to the style of some  
> parts of the algorithm and the use of flags to couple pieces of the  
> algorithm - particularly the shared algorithms at 5.2.1 which have steps  
> that say "...go to the next overall set of steps." or "Terminate the  
> overall algorithm and... " which are first read with no sense of the  
> overaal algorithm from which they are invoked.

Yes, I agree it is kind of tricky. I can move the section around if that  
would make it better and maybe include your steps below as an informative  
guide to the algorithm. Would that help?


> On the intention of the algorithm: I intuit it to be the following,  
> based on reading it's description:
>
> 1) For a given allow or deny access rule:
>          the set of allowed or denied request URIs is:
>                  a) the union of all those URI which match one or more  
> allow or deny pattern, 'minus'
>                  b) the set of URIs that match one or more of any  
> exclude pattern that is present.

Yes.


> 2) Allow access is by method - for a given method the allow set is the  
> union of all allow rules
>    which cite that method (ie. exclusions are localised to each rule) -  
> arising from
>    either access-control headers or embedded access-control PIs.

Yes.


> 3) Deny access is method independent: the overall set of denied request  
> URIs is the union of all
>    such sets arising from either access-control headers or embedded  
> access-control PIs.

Yes.


> 4) Access denial takes precidence: if a request URI is present in both  
> the overall deny and
>    the relevant method specifc allow sets, the access is denied.

Yes.


> 5) Rule ordering and partitioning between http headers and embedded PIs  
> is irrelvant to
>    the result of the algorithm

For XML documents, yes.


> Note: the operation of the algorithm as described checks set membership  
> in an intentional
> way through pattern matching rather than in an extensional manner (by  
> enumerating members).

I'm sorry, I don't quite follow this comment.


> I think this is a correct statement of the intent of the algorithm. If  
> that is indeed the case it is a basis on which test cases may be  
> specified.
>
> Also, in large part is then serves as an expression of what the access  
> control check is and ANY algorithm which satisfies those intentions  
> would do - in fact in large part it oviated the need to articulate any  
> particular algorithm in section 5.




-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 11 December 2007 17:24:25 UTC