Review of 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