W3C home > Mailing lists > Public > public-appformats@w3.org > December 2007

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

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 12 Dec 2007 13:55:29 +0100
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "public-appformats@w3.org" <public-appformats@w3.org>
Message-ID: <op.t273ir1q64w2qv@annevk-t60.oslo.opera.com>

On Wed, 12 Dec 2007 12:21:23 +0100, Williams, Stuart (HP Labs, Bristol)  
<skw@hp.com> wrote:
>> I tried making it a more clear by talking about "Web page" and "image"  
>> and "data of a resource" which seems more in line with AWWW while  
>> remaining
>> relatively easy to read and understandable to myself. :-) I hope that
>> helps.
> I'll review again in due course.
> A trouble with terms like "web page" and "image" when one is trying to  
> speak with some precision is that, at least for a "web page" there are  
> three things that could be being referred to:
> 1) What is rendered to the user on the screen - a visual presentation of  
> what was transferred over the net.
> 2) The bits transferred (an HTML serialisation) - a  
> webarch:Representation.
> 3) The web page in an abstract sense, a webarch:Resource, which could  
> have multiple representations (of the same page - .PS, .PDF, .HTML....).
> It is easy to write narrative where it is not clear whether one is  
> speaking of a "web page" in with as webarch:Representation kind of a  
> thing, or a webarch:Resource kind of a thing and it is easy to slide  
> between the two senses. /me has done it.

I think it is clear enough for the introduction, but if you have doubts  
after reviewing the text again I guess we can change the text.

>> The idea is that a Web page on domain A can use an image on domain B by
>> means of <img>. The draft now clearly states this.
> Ok... though I guess that has always been the case with the web - eg.  
> Norm regularly uses flickr hosted images in his blog pages.

Correct. Some types of cross-site requests are allowed and some are not.

> I wasn't aware of there being enforced cross-site restrictions in such  
> usages or that they are a particlar design centre for this work.

<img> is an example of something that already allows cross-site requests.

>> Cross-site requests in the draft are not restricted to scripting. For
>> instance, attaching cross-site XBL bindings does not have to involve
>> scripting.
> I'm afraid I am largely ignorant of XBL :-(, but I take its as away of  
> binding things (including behaviours) to the presentation of a  
> document/web-page.
> I don't understand how a client would discriminate between references  
> that it would subject to access controls and those that it would not.

That depends on the specification that defines the technology.  
XMLHttpRequest Level 2 defines for instance that for non same-orign URIs  
(basically comparing scheme, ihost, and the port component of the URI) you  
have to follow the algorithms defined by this specification.

>>> 2) Re: 4.3 <?access-control?> PI
>>> The 2nd para has not been fully updated to cover the addition of the
>>> "method" pseudo attribute. eg. three->four and the value of a "method"
>>> is *not* an "access item".
>> Actually, it is. It talks about three attributes of type X and one
>> attribute of type Y.
> Mostly my bad re counting (doh!), though:
>         "If an attribute is specified it must at least contain an access  
> item."
> could be a little tighter since the "method" pseudo attribute does not  
> convey an "access item".


>> Would moving this down help? Similarly to your suggestion for the
>> processing model algorithm?
> I think so... ie 'unfolding' algorithm from it's top-level down it's  
> leaves.


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

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

> 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.  
Writing tests against this also isn't too hard. I suppose it depends on  
what you're used to.

Kind regards,

Anne van Kesteren
Received on Wednesday, 12 December 2007 12:54:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:08 UTC