- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 22 Jan 2008 22:36:10 -0800
- 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