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