Re: Comments on Access Control (http://www.w3.org/TR/access-control/)

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  
<marcsil@windows.microsoft.com> 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/>

Received on Thursday, 10 May 2007 11:14:57 UTC