Hello Anne, David, wrt:
> > 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. FWIW I have reflected on the technical matter a little more. For those that didn't get the point of my comment I'll try a short recap: Section 5.1.3 [1] of the document under discusson describes the checks made in the case of Non-Get methods, for instance in the event of an attempted POST operation. In particular, upto two access control checks are made for such operations: #1: Steps 1-4: perform an initial access check to determine whether the given Non-GET operation is to be allowed to be initiated by the client (or not). #2: Step 5 (under the trailing Otherwise clause) makes further access control check based on access control information present in the response. The issue I raised is that the first check could succeed, allowing an operation, say a POST, to proceed/progress, whilst the second may fail, supressing both the response code and the response from the requesting client. In the case of a POST (or a DELETE) the client is allowed to go ahead with a potentially state changing operation denied access to not only the response, but also the response code - being informed (falsely) that a network has caused failure. The pragmatic view (to which I think Anne refers) is to take the view that #1 passing and #2 failing is likely to be a rare case (to which I agree in prinicipal that it is - modulo Murphy's Law). I'd also be willing to accept (I suppose) that the origin server or applications should not change access control content between #1 and #2 in such a way that #1 passes and #2 can subsequently fail - again modulo the practical reality of a need to occasionally change AC lists. My reflection over the New Year break period is simply as follows: I think that AC decision should be made wrt to operation as a whole (GET, PUT, POST, DELETE...) ie. given a permission to proceed with an operation it should then be allowed to run to it's normal termination. At spec'd at present, AC decisions are made on each 'phase' of a two-phase operation - spliting state-changing operation in a way that potential allows partial success and a 'split-horizon' view of the outcome (one party thinks success the other is not allowed to find out). So... on the purity side; I think the granularity of AC decisions should be whole operations... and, as an aside, intentional language that described the intended grain size is would be helpful whether or not you agree with me over what that grain size should be. Cheers, Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
