W3C home > Mailing lists > Public > public-appformats@w3.org > May 2007

No path in access item, etc.

From: Tim Berners-Lee <timbl@w3.org>
Date: Mon, 21 May 2007 10:47:11 -0400
Message-Id: <F3302912-5737-477A-A3DA-AAE0931C9B0E@w3.org>
To: public-appformats@w3.org

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
Received on Monday, 21 May 2007 14:47:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:22 GMT