On Wed, 09 Jan 2008 01:30:27 +0100, David Orchard <[EMAIL PROTECTED]> 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/>
