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 08:22:23 -0700
Message-ID: <454375AF.6060300@tellme.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>

Anne van Kesteren wrote:
>
> Below is some sort of proposal of how the access control thing can 
> work. (Lots of things are not new, fwiw.) It essentially says that the 
> specification only defines an access control policy. When that policy 
> applies and how its various return states are treated depends on the 
> specification that uses it.
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 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.).  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. 
> 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.
>
> 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. 

--Brad
>
> Otherwise, combine the rulesets from HTTP with those from the document 
> level (given by the processing instruction(s)) and, together with the 
> request URI, give these as input to the access control policy. Return 
> one of the three states.
>
> If any of the HTTP level or processing instructions are in error 
> (invalid syntax, etc.) user agents must return "access denied" and 
> terminate the algorithm.
>
>
> --Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>
>
>
Received on Saturday, 28 October 2006 15:22:38 UTC

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