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

Fwd: Access Control open/raised issues

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 17 Jan 2008 15:15:30 -0500
Message-Id: <B745A1B0-4762-48B6-8931-0274FDCB2D75@nokia.com>
To: public-appformats@w3.org

Jonas, Anne - thanks for taking the lead on this.

WG Members - please submit your comments on the AC-related Open and  
Raised Issues by January 22 at the latest. As we have been doing, we  
will assume silence means you are OK with the Editor's position:


Regards, Art Barstow

Begin forwarded message:

> Resent-From: public-appformats@w3.org
> From: "ext Jonas Sicking" <jonas@sicking.cc>
> Date: January 17, 2008 2:32:18 PM EST
> To: Anne van Kesteren <annevk@opera.com>
> Cc: "WAF WG (public)" <public-appformats@w3.org>
> Subject: Re: Access Control open/raised issues
> Archived-At: <http://www.w3.org/mid/478FAD42.2030608@sicking.cc>
> 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 20:16:53 UTC

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