Re: Review of http://www.w3.org/TR/2007/WD-access-control-20071126/

On Wed, 12 Dec 2007 14:30:42 +0100, Williams, Stuart (HP Labs, Bristol)  
<skw@hp.com> wrote:
>> The authorization request could return something different
>> from the actual request. Now that is likely to be a mistake,
>> but to be on the safe side it is better to not expose the
>> data in that case.
>
> I can see that the hiding the data from the client may be appropriate. I  
> can't tell whether or not the HTTP response code is (intended to be)  
> available so that it is a little more aware of the outcome of  
> potentially state changing network operations - "network error" is a  
> little coarse grain!
>
> All that said... this is an ugly (and hopefully unlikely) corner case -  
> I'm just a little bothered that the successful outcome (or otherwise) of  
> the networked operation may be masked by the potential need to hide the  
> content of the response from the client.

Security trumps purity. Not sure what else to say here.


>> I agree that it looks nicer, but I'm afraid to introduce
>> errors using that kind of style.
>
> Certainly, I think that is impossible to review the agorithm without  
> knowing what it's supposed to accomplish - so at least for the purposes  
> of techincal review I think the inclusion of such statements are  
> valuable. I think that they would also aid understanding either for  
> folks writing a spec that uses this spec, or for an implementor.

I think there are some problems with introducing the same algorithm  
non-normatively in a contrain-based style:

  1. There might be differences
  2. It might confuse implementors

Both do not seem good for interoperability and given the security  
implications of the specification this could be problematic. If  
(potential) implementors could give feedback on this that would be most  
valuable.


>> It is very clear what is required as the algorithm states that exactly.
>
> Actually the algorithm is only an implict statement of its own  
> requirement - it describes how it operates; what it is intended to  
> achieve is left implicit.
>
> Provided the algorithm is correct (ie. does what it's supposed to do)  
> then the imperative statement of the algorithm is indeed one way of  
> stating (implicitly) what it does. But how are we to tell if it's  
> correct if we don't say what it's supposed to do?

I think that's the wrong way of looking at it. You want to look if for a  
certain (evil) input A the results of the algorithm are not desirable.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Wednesday, 12 December 2007 14:55:11 UTC