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 14:56
> 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 14:30:42 +0100, Williams, Stuart (HP
> Labs, Bristol) <skw@hp.com> wrote:
>
> Security trumps purity. Not sure what else to say here.

I think that's just a little too pithy! Corner cases are juts tricky to get right and A trumps B doesn't really cut it IMO - plus I think it's pretty to hard to make a hard security based argument - that information left the origin server, it passed through numerous wires, probably in clear, along with the access control headers (visible), through who knows how many proxies that could 'fiddle' with them - do you authenticate the access control headers (they can certainly be tampered with)? should you?

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

What I offered doesn't present an algorithm, it was an attempt to say, explicitly, what the algorithm is intended to accomplish ('what' rather than 'how').

The algorithm "does what it does" is hardly a good basis on which to review the spec.

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

Well, if you don't say what the algorithm is supposed to accomplish... no-one can review the spec for the correctness of the algorithm!
Best they can says is... "well it does what it does". Maybe there's a requirements document or a design document that captures what the algorithm is required to do which reviewers should be reviewing the document against?

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

I think I should leave you to discuss this with your WG - I doubt I'd do much more than repeat myself by continuing.

Regards

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

Received on Wednesday, 12 December 2007 16:29:17 UTC