[AC] proposal on how to move forward

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.

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

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.

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 10:20:29 UTC