Re: Access Control open/raised issues

On Jan 17, 2008, at 2:32 PM, ext Jonas Sicking wrote:

> 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.

I view this more as an editorial enhancement request rather than an  
issue so I agree with closing it. Of course, if anyone submits an  
input to address this issue we can discuss it ...


>> 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]

I'm OK with closing this (covered by the new requirements appendix).


>> 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.

David and Stuart submitted a substantial proposal but I didn't see  
anyone support it. I mentioned last month I see some value in adding  
some descriptive (non-normative) text to describe the general  
algorithms. However, given the lack of support for the latest counter- 
proposal, I tend to agree with Anne and Jonas and I am OK with  
closing this issue.


>> 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.

I think the latest ED addresses this issue much better than it did  
when the issue was raised last August. I also think this issue is  
mostly covered by issue #21 so I am OK with closing it.


>> 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 agree Brad and Ian covered the rationale behind the model and I  
think we now have at least some  documentation in the spec to  
substantiate this design. Consequently, I'm OK with closing issue  
this issue.

However, clearly some of the commentors don't like this model. I'm  
open to suggestions on how to address these concerns e.g. a new  
Incubator Group, etc.


>> 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.

Regarding #19, I think we've made good progress in the last week but  
there is some more work to do and I will submit related comments  
separately. I am inclined to leave this open for now.

Regarding #21, I would be inclined to leave it open and solicit input  
but we probably don't need to wait for such an input before advancing  
the document to LC.

Regards, Art Barstow
---

Received on Tuesday, 22 January 2008 20:25:40 UTC