W3C home > Mailing lists > Public > public-appformats@w3.org > October 2006

Re: [AC] proposal on how to move forward

From: Brad Porter <brad@tellme.com>
Date: Sat, 28 Oct 2006 15:49:21 -0700
Message-ID: <4543DE71.5030202@tellme.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>

Anne van Kesteren wrote:
> On Sat, 28 Oct 2006 17:22:23 +0200, Brad Porter <brad@tellme.com> wrote:
>> I can go either way on this.  The original NOTE was targeted to a 
>> very specific use-case and not intended to be a generalized access 
>> mechanism.  That use case (XML read by applications running in a 
>> browser) is an important use case by itself.
> I agree. This specification doesn't prohibit that though. VoiceXML 
> would just say that for non-same-origin resources the access control 
> policy as defined in [ACCESS-CONTROL] is applicable and what it would 
> mean for that resource to be in "default", "allow" or "deny" state.
You are correct, the specification doesn't really prohibit other 
specifications using the mechanism for other use cases.  Though the 
title/abstract/introduction in particular used to be much more specific 
on the intended use-case for this mechanism (XML read by browser 

The problem with letting other specifications define how to use the 
mechanism is that unless we specify some way to specify 
access-control-for-function-X, then two specifications might declare two 
different purposes for the header which conflict. 

For instance, a specification might say "if access-control is deny for a 
document to be displayed in a sub-frame, the contents of that document 
must not be displayed in the sub-frame."   Another specification might 
say "if access-control is deny for a document to be requested by 
XmlHttpRequest, the contents of that document must not be parsed and 
made available to the application."

As an author, if you want to allow your content to be displayed as a 
sub-frame, but not allow your content to be accessed via XmlHttpRequest, 
what do you do? 

As I said, I could go either way, but if we just want to say "this is a 
mechanism independent of function, here you go, you must specify the 
functional behavior in its context", then I think we need to enable a 
way to say "access-control-for-function-X". 

Currently, the specification states "

>> I don't feel like we've analyzed enough general use-cases for 
>> access-control to say that the mechanism is sufficiently general for 
>> the variety of use-cases that have been mentioned (restricting access 
>> to images, etc.).
> Note that my proposal is not to make it generic. It just says that 
> other specifications have to define when you have to apply the access 
> control policy to a resource and what it would mean for such a 
> resource to be in one of the three returned states.
>> That said, we could also leave that analysis exercise to those 
>> writing the specification that references this. I do worry that if 
>> there are two separate access-control use cases applicable to a 
>> single document (disallow access for X, but allow access for Y) then 
>> we could be in conflict.
> I don't really understand this.
See description above. 
>>> The allow and deny ruleset, together with the request URI (referrer) 
>>> form an input for the access control policy. The outcome is either 
>>> "access denied", "access granted" or "default" (or something along 
>>> those lines).
>>> Specifications using this specification must define for which 
>>> resources the access control policy is applicable. Those 
>>> specifications must also define what "access denied", "access 
>>> granted" and "default" mean in the context of that specification 
>>> (throwing an exception, etc.). (XXX: I suppose that in most cases 
>>> "default" is treated as "access denied". Not sure how to say that 
>>> here though.)
>> Yes, though if we want to make it general, I don't think we can 
>> specify a default.  For instance, the <img src=""> case should 
>> probably default to allow.
> In the case of <img src=""> the whole access control policy probably 
> doesn't apply at all. (Unless you want it and in that case you'd have 
> to define that in the relevant specification...)
Right, I'm suggesting we either want to consider those potential use 
cases, or we should state that this is not intended for that purpose and 
it isn't appropriate to reference/use this mechanism for anything other 
than XML-read 
>>> XXX: Probably say something about this only being safe for GET and 
>>> HEAD requests.
>>> When fetching a resource the following algorithm must be followed:
>>> When a resource is retrieved over HTTP extract a deny and allow 
>>> ruleset from the Access-Control (XXX: Content-Access-Control?) 
>>> header(s). That, together with the request URI, forms an input for 
>>> the access control policy. If the result is "access denied" return 
>>> that and terminate the algorithm.
>> I missed the justification for HTTP overriding document level?  Is 
>> this just to support priority of protocol over content?  The use case 
>> that a web-server might generally disallow, but a document wants to 
>> specifically allow in certain cases seems quite valid.
> Something like
>   Content-Access-Control:deny="*"
>   <?access-control allow="foobar.com"?>
> I suppose that's a valid issue. I'm fine either way so I suggest the 
> specification says to take both into account and only HTTP for HEAD 
> requests. 
The specification does currently say that rules may be specified in both 
places and that all rules must be used.  Consequently, the most 
appropriate reading is that HEAD-only requests are insufficient to make 
a determination.  Do we have a use-case for HEAD-only requests?

> --Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
Received on Saturday, 28 October 2006 22:49:46 UTC

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