W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: Feedback on Access Control

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 22 Jan 2008 22:36:10 -0800
Message-ID: <4796E05A.3080500@sicking.cc>
To: Mark Nottingham <mnot@yahoo-inc.com>
Cc: Anne van Kesteren <annevk@opera.com>, "WAF WG (public)" <public-appformats@w3.org>

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 
>> <mnot@yahoo-inc.com> wrote:
>>> On 22/01/2008, at 8:59 PM, Anne van Kesteren wrote:
>>>> On Tue, 22 Jan 2008 04:56:52 +0100, Mark Nottingham <mnot@yahoo-inc.com
>>>>> [...] 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 
enough?

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 
policy.

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


[1] http://www.w3.org/TR/P3P/#ref_syntax
Received on Wednesday, 23 January 2008 06:36:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC