Reviewing http://www.w3.org/TR/access-control/
http://www.w3.org/TR/2007/WD-access-control-20070215/
1. The term "request URI" is a confusing term for the URI of the
source making the request, when the HTTP request has a URI in it
which is the requested URI. It isn't the URI of the requesting
client, either. Suggest: codebase URI? This is like 'codebase
principals' in existing security models.
2. The inability to specify a path as an access item is a problem.
For example, there is a lot of stuff I wouldn't vouch for on, for
example, www.w3.org, or on csail.mit.edu, but specific paths which I
would trust more. A path prefix is needed. Why was it omitted.
3. When implementing the access system, restricting access items to
be (with domain fields reversed) prefixes would make matching easy
and fast. (You can order the prefixes, and quickly find the match in
a long list. Not that you have long lists in the examples, but I'd
note that this sort fo stuff may get picked up by all kinds of other
specs.)
http://*.example.com/ becomes a prefix http://com.example.
http://www.w23.org/2007/safescripts/* is just http://www.w23.org/
2007/safescripts
The constraint means you can't have http://*.example.com/fred/* as
there are wildcards at two levels separated by a constant.
I feel it is wise to keep the matching really simple, rather than
(say) regexps.
(I'm sorry the domain name fields are the way they are, that is a bug
we have to work around :-/ )
Tim
