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

Re: [AC] proposal on how to move forward

From: Anne van Kesteren <annevk@opera.com>
Date: Sat, 28 Oct 2006 18:29:19 +0200
To: Brad Porter <brad@tellme.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-id: <op.th4325s064w2qv@id-c0020.oslo.opera.com>

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.


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


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


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


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Saturday, 28 October 2006 16:29:40 UTC

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