W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: Access Control open/raised issues

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 17 Jan 2008 11:32:18 -0800
Message-ID: <478FAD42.2030608@sicking.cc>
To: Anne van Kesteren <annevk@opera.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>

Anne van Kesteren wrote:
> 
> I was surprised that a large number of issues is still open. An attempt 
> to get some closed.
> 
> 
> ISSUE-4 http://www.w3.org/2005/06/tracker/waf/issues/4
> 
> I don't think we need this distinction and I already replied to the 
> relevant comment. The specification is clear enough on this point.

Agreed.

> ISSUE-5 http://www.w3.org/2005/06/tracker/waf/issues/5
> 
> We have both black- and whitelisting for the following reaons: In case 
> the server and documents hosted on the server are in control by 
> different people it is necessary that the server people are able to 
> override the document people (if the document wants to share access) and 
> vice versa (if the server wants to share access).
> 
> I suggest we close this issue because there's a good reason to have the 
> deny rule.

Black lists are required to satisfy point 7 from [1]

> ISSUE-11 http://www.w3.org/2005/06/tracker/waf/issues/11
> 
> The specification states: "User agents may optimize any algorithm given 
> in this specification, so long as the end result is indistinguishable 
> from the result that would be obtained by the specification's 
> algorithms." This seems clear enough to me. I suggest we close this issue.

Agreed.

> ISSUE-16 http://www.w3.org/2005/06/tracker/waf/issues/16
> 
> I have added more information to the introduction. Together with the use 
> cases and requirements document/appendix I think we'll cover this 
> adequately. I suggest we close this issue.

Yep, the requirements doc satisfies this I think.

> ISSUE-20 http://www.w3.org/2005/06/tracker/waf/issues/20
> 
> I think the current model is adequate and leaves the server in control 
> at all times. It has been explained on the mailing list why we have this 
> model by Brad and Ian mostly so I think we can close this issue.

This is required by point 3 in [1]. Also, the client already is a PEP on 
he web today, as well as in all other proposals I've seen (such as 
JSONRequest)

> I'm not sure what to do with ISSUE-21. It's not concrete enough to do 
> anything with and as far as detailing what needs to be done for security 
> I think that's already covered. I suggest we close this one. ISSUE-19 
> will be dealt with when we publish the requirements document/appendix.

I think [2] describes the threat model. If it's unclear we can expand it.

[1]
http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0193.html
[2]
http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0195.html
Received on Thursday, 17 January 2008 19:32:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC