Re: Feedback on Access Control

Mark Nottingham wrote:
> On 23/01/2008, at 5:36 PM, Jonas Sicking wrote:
>> 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.
> 
> While the web architectural implications of a "magic" well-known 
> location are known, it's also an eminently practical solution, one 
> that's been used not only for P3P, but also robots.txt and site maps 
> (which leverages robots). Why is this problem so different that it 
> requires people to learn a whole new way to associate policy with 
> resources?
> 
> Saying "hixie is very much against it" utterly fails to convince me; 
> provide use cases, requirements, and specific rationale for the 
> trade-offs made and gain consensus on them. Document the good arguments.

It'd be great if others could step up here as this isn't something I've 
looked into a lot.

>> 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.
> 
> It depends. Having a well-known location means that policy only has to 
> be retrieved once per site, rather than once per resource.

You still have to retrieve the url of the policy every time. Granted, if 
the policy is big then the url could be meaningfully shorter. It does 
make the simple cases more chatty though (two GETs rather than one).

/ Jonas

Received on Wednesday, 23 January 2008 08:34:26 UTC