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