Re: P3P - Feedback on Access Control

On 24/01/2008, at 12:11 PM, Ian Hickson wrote:

> On Thu, 24 Jan 2008, Mark Nottingham wrote:
>>
>> The heart of the issue is how policy is discovered; the current ED  
>> uses
>> a per-resource OPTIONS, while almost every other solution in this  
>> space
>> uses a well-known-location.
>
> robots.txt is a per-domain policy (to prevent a host from being
> overwhelmed); there are per-resource ways of controlling spiders as  
> well.

So why not take that approach? E.g., HTTP headers / PI for safe  
methods, well-known location (or an addition to robots.txt) for unsafe  
methods.


> p3p.xml is a per-domain policy intended to be fetched before the  
> resource
> in question is fetched, for reasons that don't apply here. There are  
> also
> ways of providing per-resource information for this policy.  
> Furthermore,
> P3P has had such a poor uptake that I don't think it's a good thing to
> look at.

For reasons that are completely unrelated.


> Sitemaps are site-specific (domain-specific) and are intended to act  
> as a
> manifest for other resources, and thus wouldn't make sense at a
> per-resource level.
>
> None of these seem appropriate precedents for Access Control, which is
> specifically a per-resource concern.

What does that really mean? Whether or not a spider can access  
something, whether or not a privacy policy applies, and what metadata  
is associated is also a "per-resource concern."


>> The decision to Recommend a new mechanism for discovering policy
>> shouldn't be taken lightly.
>
> I hardly think that HTTP headers and "OPTIONS" can be called a "new
> mechanism". After all, every per-resource policy mechanism uses them
> already!

Which other per-resource policy mechanism uses OPTIONS (discounting  
WebDAV, which is a stretch here)? I have no quarrel with using HTTP  
headers / PIs for GET responses; it's the per-resource authorisation  
request (whether OPTIONS or GET) that is problematic.


>> I've pointed out several problems with the current proposal, and  
>> haven't
>> received satisfactory responses to many of them.
>
> As far as I can tell, all feedback has been responded to -- can you be
> more specific as to what technical feedback hasn't been answered?

* Inability to cache OPTIONS, and the resulting problems for scaling  
this mechanism by caching policy in anything but the client
* per-resource OPTIONS requests are too chatty, don't scale to large  
numbers of resources, eventually causing developers to come up with  
workarounds such as boxcarring messages
* Access-Control syntax is still suboptimal



--
Mark Nottingham       mnot@yahoo-inc.com

Received on Thursday, 24 January 2008 01:47:23 UTC