On Mon, 10 Dec 2007 18:57:41 +0100, Williams, Stuart (HP Labs, Bristol)
<[EMAIL PROTECTED]> 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/>
