Hi,
http://dev.w3.org/cvsweb/~checkout~/2006/waf/access-control/Overview.html?content-type=text/html;%20charset=utf-8
should resolve most of your comments. Though please see the inline
comments below for several questions.
On Thu, 03 May 2007 21:19:22 +0200, Marc Silbey
<[EMAIL PROTECTED]> wrote:
[Marc] That makes sense. We should just generalize the statement here so
that folks understand the scope. Maybe we can say:
"The access-control mechanism enables web resources to permit websites
to access their content when such access would be prohibited by same
origin policy"
Ok, made some changes to that affect, please review.
1.3. Security Considerations
COMMENT 7) "User agents which implement this capability should take care
not to expose other trusted data (cookies, HTTP header data)
inappropriately" - we should probably provide some scenarios that we're
trying to protect so readers can easily understand this
I suppose the scenario is that you're logged into a site and that site
exposes data to some other site where that data is also based on cookies.
You don't want to give other sites access to the data only the user would
get to see before.
2. Access Control Read Policy
COMMENT 9) We should define what extra safety measures are required for
HTTP methods besides HEAD and GET. We should think again about adding
POST because some folks will argue that it is as safe as GET and would
be a useful addition.
QUESTION: What happens in the case of trailing headers? Maybe we should
specify that this appears in the headers that come before the body
Can you elaborate on this a little?
COMMENT 10) Proposed rewording "When access to a resource is not
permitted by this policy, the request is said to be in error and access
to that resource MUST be denied in such a way that the status or
existence of the blocked resource is not revealed to the caller (to
prevent enumeration/fingerprinting attacks)."
It's not clear to me what text this is supposed to replace.
[Marc] It’s just adding onto the following:
"When a resource is said to be in error access to that resource must be
denied."
This is now completely changed, please review.
COMMENT 12) Proposed change to EBNF:
An access item MUST match the following EBNF:
access-item ::= scheme-specifier "://" domain-pattern ( ":"
port-specifier )? | "*"
domain-pattern ::= wildcard-label | wildcard-label "." domain
wildcard-label ::= label | "*"
scheme-specifier ::= scheme | "*"
port-specifier ::= port | "*"
Since the port is still optional what should it default to if no scheme
is provided?
[Marc] We think it should default to “*”
The access item BNF has since changed. It does not allow * for port or
scheme but it does allow them to be omitted and that would come down to
the same thing. Please see the draft.
We're concerned that allowing "example.*" wildcarding maybe
unnecessarily flexible and lead to mistakes by web developers
We agreed yesterday that maybe requiring the TLD would be good. So that
you can't omit things like .com etc. but that doesn't actually solve the
problem with .co.uk for instance. (And the various hundreds, maybe more,
more complex registration systems.) Do we really want to go there?
[Marc] We’re just trying to avoid allowing right-hand-side wildcarding.
Right. The draft should now follow your suggestion.
COMMENT 13) Proposed rewording "In addition to matching the above EBNF,
the ToASCII algorithm MUST apply successfully (without errors) to each
label component from the access item. If the access item doesn't match
the EBNF or the ToASCII algorithm fails, the request is denied."
This follows from it being in error. I suppose we can drop that though as
in error always leads to access being denied. Address later.
This is now taken care of in the new user agent processing requirements.
COMMENT 14) Proposing removal of the following examples following the
above comments on wildcards
https://*.*:80
*://example.org
http://example.org:*
I'll address the examples once the above comment is addressed.
These have been updated too.
COMMENT 15) Proposed rewording: "If the Content-Access-Control header
doesn't match the specified syntax, the request is denied." If we decide
to go with "deny" instead of "except" there are other replacements.
Similarly we should think about changing "resource is in error" to
"request is denied"
This should now be more clear.
3. Matching Algorithm
COMMENT 16) Maybe add "It should be observed that the DENY rules take
precedence over any ALLOW rules." after the first algorithm. We should
think about joining the allow and deny rulesets so the operate on the
full list together.
This is not the idea of the current algorithm. Though see above, it's not
clear we need it. Address later.
I think the revised algorithm covers this. Though please review.
COMMENT 17) Proposed changes to the second algorithm to help clarify
[...]
Could you please check if the revised algorithm has resolved your concerns?
Do you have a more complete list of names for the acknowledgements
section? Thanks!
[Marc] Eric Lawrence; Sunava Dutta; Sharath Udupa; Zhenbin Xu;
Added, thanks!
Kind regards,
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
