Re: Feedback on Access Control

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.

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

No particular argument there.

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


--
Mark Nottingham       mnot@yahoo-inc.com

Received on Wednesday, 23 January 2008 07:16:52 UTC