- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 9 Jan 2008 07:46:54 -0500
- To: ext Thomas Roessler <tlr@w3.org>
- Cc: Anne van Kesteren <annevk@opera.com>, Mark Nottingham <mnot@yahoo-inc.com>, Ian Hickson <ian@hixie.ch>, "Close, Tyler J." <tyler.close@hp.com>, "public-appformats@w3.org" <public-appformats@w3.org>
Thomas, On Jan 8, 2008, at 6:16 PM, ext Thomas Roessler wrote: > > (Finally catching up on WG mail after the new year's break.) > > On 2008-01-03 09:54:29 +0100, Anne van Kesteren wrote: > >> On Thu, 03 Jan 2008 02:26:57 +0100, Mark Nottingham <mnot@yahoo- >> inc.com> > >>> Has the working group gained consensus on this requirements list and >>> documented it? > >> As far as I can tell the Working Group has always worked with these >> constraints in mind, but we never put them in a document. > > For the record, there was a lengthy discussion at the technical > plenary that, I believe, there is no final agreement on the "no > server implementation effort" requirement. Yes it is true we never formally captured a resolution/agreement regarding "no sever implementation". OTOH, there has also never been any type of resolution/agreement that we would change our working assumption - that we've been using since we started with the client- side model documented in the VB Read Access model [VB-Note] - that the User Agent is a Web Browser (or Voice browser). Regards, Art Barstow --- [VB-Note] <http://www.w3.org/TR/2005/NOTE-access-control-20050613/> > > Also, among these requirements, "server ultimately controls access" > is *very* ambiguous. > > To begin with, the distinction between a cross-site access to a > resource and a first-party access to that resource is one that, > ultimately, only the client can make. Therefore, any enforcement > mechanism *will* trust the client with a critical piece of > information, whether that mechanism performs computation on the > server or on the client. One can draw different conclusions from > this, depending on what part of the overall complexity one wants to > keep down. > > Further, for GET, the protection goal is controlling a data flow > that is opened up *within* the client (and is currently blocked). > > For POST and other methods, avoiding spontaneous requests seems to > have crept in as well. As I said before, I'm very doubtful how > useful that is as a protection goal any more -- I think that horse > has left the barn, quite some time ago. > > Cheers, > -- > Thomas Roessler, W3C <tlr@w3.org> >
Received on Wednesday, 9 January 2008 13:44:21 UTC