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

Hello Anne,

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@opera.com]
> Sent: 12 December 2007 12:55
> To: Williams, Stuart (HP Labs, Bristol); public-appformats@w3.org
> Subject: Re: Review of
> http://www.w3.org/TR/2007/WD-access-control-20071126/
>
> On Wed, 12 Dec 2007 12:21:23 +0100, Williams, Stuart (HP
> Labs, Bristol) <skw@hp.com> wrote:

<snip/>

> >> Step 5 is not an otherwise clause. I'll assume that was a mistake.
> >
> > I was referring to the "Otherwise" clause at the *end* of step 5. The
> > para immediately before the section 5.2 heading:
> >
> > "Otherwise
> >         Perform an access control check using the request method as
> >             method. If it returns "fail"
> >         remove the cache entry, then terminate this algorithm, and
> >             return with the status flag
> >         set to "network". Otherwise, if it returns "pass", terminate
> >             this algorithm and return
> >         with the status flag set to "success". Do not actually
> >             terminate the request."
>
> Ah, I see.
>
>
> >> The access policy protects the information that is part of the response.
> >> The request itself is protected by the authorization request that is
> >> made before this one (or the authorization request cache).
> >
> > FWIW I think I'd agree that except around the the time of a change in
> > access policy the algorithm one should never reach this point. The
> > authorization check should prevent the networked operation happening
> > in the first place.
>
> 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.

> >> Yes, I agree it is kind of tricky. I can move the section around if
> >> that would make it better and maybe include your steps below as an
> >> informative guide to the algorithm. Would that help?
> >
> > I think so... the numbered 'statement' that I offered where (my)
> > attempt to capture what the algorithm is designed to  accomplish - ie.
> > they are intended (roughly) as a declarative (though possibly flawed)
> > expression of what the algorithm is supposed to do rather than a set
> > of procedures to follow - ie. they are intend as factual or truthful
> > assertions about the algorithm, not an imperative process.
>
> 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.


> > Personnally, I think that such an expression (corrected if necessary
> > to accurately capture the design intent) is a powerful tool. It can
> > provide a basis on which to create test cases and to judge whether
> > access should/should not be denied so that the algorithm itself as
> > well as it's implementation can be road-tested.
> > In fact, without such an expression there really is no way to judge
> > whether the algorithm does what is required of it (because it isn't
> > stated).
>
> 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?

> Writing tests against this also isn't too hard. I suppose it depends on what you're used to.
>
> Kind regards,
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>

regards

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Wednesday, 12 December 2007 13:37:28 UTC