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

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

Jon




                                                                           
             "David Orchard"                                               
             <dorchard@bea.com                                             
             >                                                          To 
             Sent by:                  "WAF WG (public)"                   
             public-appformats         <public-appformats@w3.org>          
             -request@w3.org                                            cc 
                                       <www-tag@w3.org>                    
                                                                   Subject 
             01/08/2008 04:30          Review of                           
             PM                        http://www.w3.org/TR/2007/WD-access 
                                       -control-20071126/                  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I have an action from the TAG to review
http://www.w3.org/TR/2007/WD-access-control-20071126/

Please regard the attached as personal comments. The TAG may subsequently
choose to support some, all or none of them.

I agree with every one of Stuart Williams' comments [1] , as well as his
follow up comments on the mailing list.  I orginally wrote up my comments
before reading Stuart's comments and the follow-ups to ensure some "clean
room" aspects to my review and afterwards I found that there was very
significant overlap.  I then mostly removed the duplicates to ensure no
redundancy of comments. I have divided my comments into substantive then
editorial.

Substantive
----------------
PEP in the client
I'm concerned about the decision to have the client be a PEP, and the
commensurate need to create a new policy language.  The Security Context
Working Group member Tyler's comments [2] and the extended discussion have
not convinced me that his proposed simplification, or some other similar
proposal, is not worth pursuing.  I support continued examination of a
server-side only PEP. I believe this is issue #20 afore the WG.

Algorithm
I believe that specifying algorithms in the style of the document suffer
from significant drawbacks, particularly that there may be implementations
that can achieve the desired functionality that do not follow the algorithm
as written.  Stuart is correct in his discussion of intentional versus
extensional styles and I wholeheartedly agree with his suggestion.  In
general, I would like to see each of the items defined and what the full
set of constraints on each item are .   There are many constraints that are
embedded in the algorithm that ought to be called out into the definitions.
I strongly agree with removing the "algorithms" in favour of definitions.
I would be glad to attempt such a document rewrite and Art has suggested I
do so.  I believe this is issue #11 afore the WG.

HTTP Method for Authorization Request
The specification uses HTTP GET for the Authorization Request, with the
Method-Check HTTP Request Header.  This seems an inappropriate HTTP Method
because the resource identified by the URI is not being dereferenced,
rather the intent is to retrieve either Access-Control headers or the
<?Access-Control?> Processing Instructions.  There aren't clear
requirements that indicate why other HTTP methods such as HEAD or OPTIONS
aren't used instead or in addition to.  I think this is closed issue #7,
but I'm not sure.

Authorization Request data
I don't quite follow the details of Stuart and Anne's intereractions on
this topic, but it does seem to me that the response of "Security trumps
purity. Not sure what else to say here." is unhelpful and almost
disrespectful to a very qualified reviewer.  Security does not trump
anything, security is all about trade-offs.  If it was all about security,
we'd have a very different world including no f2f meetings.  I don't see
the specific issue that Stuart raised in the issues list, and if it is
indeed not there, it ought to be.

Requirements, use-cases.
These are needed.  Discussions, such as issue #20, are bringing up some
very finely detailed requirements that are not at all obvious to the reader
of the documents.  I believe this is issue #19 afore the WG.  I have
written up a very rough version for the WG to use as it sees fit. [3]

Liaison
As I'm sure the WG knows, there is a new HTTP Working Group formed.  I
encourage the WAF working group to form a liaison with the HTTP WG for
reviews and comments.

Editorial
------------
Section 1. Introduction
I found the Introduction, the problems that were attempted to be solved by
restriction of cross-site, and the motivations a little unclear.  The use
of the vertical bar on the left starting at "If you have" and running to
"<?access-control" wasn't very helpful.  I think it is intended for
examples, but a page long example that breaks before the end of an example
didn't help me.  I found the use of "you" confusing because I would assume
that there would be browser implementers, page authors, and server
configurers that would all use this document.  There is no rationale given
for why the client can be trusted as a PEP.   I think the introduction
could do with more examples of the message flows.  For example, the
cross-site requests using DELETE and POST should have the authorization
request, the authorization response, an allowable actual request, and then
the response to the actual request as shown.  Or is the "response to the
actual request" shown actually a response to the authorization request?
Not clear.  Further, I'd show the auth request with caching, then a request
in the presence of cached results.

Section 3. Security Considerations
Given the current use of script for cross domain, how does an author
validate the content before rendering or executing?
The spec says "authors SHOULD ensure", and I believe that per HTTP, they
actual MUST ensure.  If a response to a GET has side-effects, then it is
not an HTTP GET.

Section 4.1 Access Item
As access-item is used as part of the Access-Control and could be part of
either deny or allow, how does the 2nd set of items imply "would make the
user agent deny access to the resource"?

4.3 <?access-control?>
There is an implication that a maximum of 1 <?access-control?> pi can be
within the prolog (by the use of "an", etc.) but I'd like it to be very
clear.  For example, the text says"An XML Resource MAY include an.... ".  I
think the intent is that there may be more than one, judging by the later
algorithms.  How about "An XML Resource MAY include one or more
...<?access-control?> PI".  This is an example of the style that I prefer.

4.4 Referer-Root.
Is the Referer-Root required or not for cross-site access requests?  If
required it should be stated as such, if not then behaviour under presence
and non-resence of the header should be specified.  Style comment again.

5. Processing Model.
How does a specification implement a processing model?

Why specify a streaming xml parser?  Presumably I could implement this,
admitedly probably with poor performance, in a non-stream parser?  Is this
a MUST or SHOULD, and if so, how is this tested?

Cheers,
Dave Orchard

[1] http://lists.w3.org/Archives/Public/public-appformats/2007Dec/0020.html
[2] http://lists.w3.org/Archives/Public/public-appformats/2007Dec/0054.html
[3] http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0091.html