Re: Review of http://www.w3.org/TR/2007/WD-access-control-20071126/

Jon Ferraiolo wrote:
> I guess that PEP = policy enforcement point
> 
> Regarding PEP in the client, I agree with David Baron that there has to 
> be a security policy in the client, and in fact there already is such a 
> policy (i.e., the same-domain policy). However, I also agree with David 
> Orchard that enforcement of which domains should be allowed to access 
> which data (i.e., the policy as expressed in Access Control's processing 
> instruction) more naturally belongs on the server, not the client.
> 
> But I would go further and question the whole approach of listing a set 
> of domains that are allowed or denied. I have a hard time seeing which 
> workflows make sense from whitelisting or blacklisting discrete domains, 
> with the possible exception of "*" (i.e., everyone) or a list of 
> subdomains within a company's intranet (although this would be fragile). 
> I much prefer the approach in JSONRequest, which does not include a list 
> of allowed/denied domains. The JSONRequest approach matches the 
> requirements of public/unprotected web services, which I believe is the 
> most important use case for cross-domain data access. JSONRequest 
> assumes that the server will decide who has access to the data, which 
> aligns with David O's recommendation. (But as I have said before, I 
> would like to see JSONRequest support XML payloads in addition to JSON 
> payloads.)

I don't think something like JSONRequest can ever satisfy the 
requirements access-control has. First off starts with a very different 
starting point security wise, which is that anything that looks like 
javascript can be read by any site. This is due to the fact that 
browsers currently let you do cross-site loading of any data that is 
parseable as javascript.

However access-control is trying to solve the problem for other data 
types as well, such as HTML and XML. These data types can currently not 
be loaded cross site, which means that there likely is documents out 
there containing sensitive information which must not be exposed cross 
site. And note that not including cookies and other auth credentials 
does not solve this problem due to content behind firewalls. While I can 
agree that relying solely on the fact that a server lives behind a 
firewall is not the best protection strategy, I expect this is currently 
in widespread use (it's something I've seen myself a lot) and so not 
something that we can ignore.

I would also like to note that JSONRequest also uses the clinent as a 
PEP. JSONRequest uses the Content-Type header to indicate that data 
should be accessible cross site and relies on the client to enforce 
that. Access-control uses the <?access-control?> PI or the 
Access-Control header instead. Which of these two headers are more 
secure can of course be debated, but the fact remains that the client is 
a PEP in both cases.

I agree that the whitelisting/blacklisting feature does not add that 
much value compared to the simple "*" case. However I do think 
especially whitelisting does add some value, and in fact the spec that 
access-control originated from had that as requirement. Also, the 
whitelisting/blacklisting in itself so far hasn't received much negative 
feedback, but rather the fact that the decision is made by the client.

I don't see how JSONRequest can be adjusted to work for any content type 
without turning it into something that looks a lot like access-control 
since it both relies on the content looking like javascript, and uses 
the Content-Type header to control access.

/ Jonas

Received on Wednesday, 9 January 2008 08:40:54 UTC