Re: Feedback on Access Control

Mark Nottingham wrote:
> On 23/01/2008, at 9:50 AM, Anne van Kesteren wrote:
>> On Tue, 22 Jan 2008 23:14:26 +0100, Mark Nottingham 
>> <> wrote:
>>> On 22/01/2008, at 8:59 PM, Anne van Kesteren wrote:
>>>> On Tue, 22 Jan 2008 04:56:52 +0100, Mark Nottingham <
>>>>> [...] Separate from the server-side vs. client-side policy 
>>>>> enforcement issue (which I'm not bringing up here explicitly, since 
>>>>> it's an open issue AFAICT, although the WG doesn't link to its 
>>>>> issues list from its home page), the Working Group needs to 
>>>>> motivate the decision to have access control policy only apply on a 
>>>>> per-resource basis, rather than per resource tree, or site-wide.
>>>> It's not an open issue.
>>> Let's have one, then. The W3C has already solved the problem of 
>>> site-wide metadata once, and there should be *some* reason for taking 
>>> a different path this time.
>> Actually, we have an open issue on this one and it's proposed for 
>> closing as we have per resource policy requirement.
> Perhaps it would be good to get consensus on requirements first...
> At any rate, take a look at P3P, which does allow per-resource policy.

I think use cases for having per-resource access is pretty easy to come 
up with. I'd rather ask, why would per server, or even per directory, be 

So P3P has a few ways to associate policies with documents [1]:
1. "magic uri"
The policy file is located at a magic uri that is defined in the 
specification. We've gotten a lot of negative feedback about this 
approach before, I know hixie is very much against it and has provided 
good arguments in the past.

2/3. <link> tag.
My main concern is that this is very (X)HTML specific. Especially since 
most of the use cases I've heard described has been about transferring 
non-html files cross domains. It also forces the implementation to parse 
potentially the whole resource before being able to determine the access 

Generally the PI syntax in the access-control spec seems like an 
improvement over this solution.

4. HTTP header.
This is a header that contains a pointer to the actual policy file. 
Seems like our solution of actually putting the access policy inside the 
header instead results in a much less chatty implementation.

/ Jonas


Received on Wednesday, 23 January 2008 06:36:40 UTC