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

On Wed, 09 Jan 2008 01:30:27 +0100, David Orchard <dorchard@bea.com> wrote:
> 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.

Given that the client is already the PEP I don't see how you can move all  
that to the server-side without introducing serious problems.


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

Specifications are free to implement them in whatever way they want as  
long as they give the same output the specification would give for any  
given input. This is part of the conformance criteria.


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

I'm ambivalent about writing style though I'm personally not sure how to  
cover it adequately in a rule based system while still covering everything  
that it needs to cover. If you show that this can be done and implementors  
prefer that approach we can change the text I suppose.


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

This has been discussed extensively already.


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

I already explained why it was the way it was. Stuart then called that  
unfortunate but a minor problem to which I replied with this line. Please  
don't quote out of context.

http://lists.w3.org/Archives/Public/public-appformats/2007Dec/0030.html


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

You have not given any new technical feedback for why this should be  
reconsidered.


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

I guess I can include requirements in the document.


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

We have requested review and feedback from them.


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

Would splitting them up be better for you, removing some examples, or what?


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

I tried to make the introduction examples informal, primarily aimed at Web  
page authors so they get a grasp of what they can do with the technology.  
If you have a suggestion on how to improve this please do tell.


> There is no rationale given for why the client can be trusted as a PEP.

The client has historically been trusted as a PEP for most things  
concerning the "Web architecture" (the Web as it exists, not referring to  
the AWWW document), because specifications never really dealt with the  
specific implementation of security issues. This is why we now have  
cross-site <img> / <script> GET requests with authentication and cookies  
enabled. Why <canvas>.toDataURL() needs to throw if a non same-origin  
<img> has been drawn upon it using drawImage(). Why one Window object  
can't access another Window crossing the same-origin boundary. And it goes  
on...

What would like to see here? "The client can be trusted because it wants  
to protect its users, keep its users, and keep a low score on  
secunia.com."?


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

I thought you wanted this to be shorter! :-)


> Or is the "response to the actual request" shown actually a response to
> the authorization request?  Not clear.

Why is that not clear? It first lists the response to the authorization  
request and the header which he response to the actual request can contain.


> Further, I'd show the auth
> request with caching, then a request in the presence of cached results.

That would be useful, noted. Though again, shorter or longer?


> 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 processing model of <script> is out of scope as it does not use the  
access control mechanism and probably never will (unless some weird API is  
added at some point in the future that lets you read the source code of a  
script in which case it would be needed).


> The spec says "authors SHOULD ensure", and I believe that per HTTP, they
> actual MUST ensure.

We can't reliably test this so therefore I used SHOULD.


> If a response to a GET has side-effects, then it is
> not an HTTP GET.

I don't see how the result of a GET request changes the nature of the  
request itself.


> 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"?

It does not matter where they are used. They would always cause access to  
be denied as they are not conforming.


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

Good point. Fixed. Are there any other instances besides that one?


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

This section describes the syntax. The processing model describes the  
headers that are to be set.


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

By normatively referencing an algorithm an dealing with the potential  
outcomes of such an algorithm.


> Why specify a streaming xml parser?

To get the same behavior everywhere.


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

This is a MUST as everything that the algorithm states is a MUST unless  
stated otherwise. You can test this by including XML namespace well-formed  
constraint violations in the document.


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


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Wednesday, 9 January 2008 11:46:04 UTC