On 03/01/2008, at 11:58 AM, Ian Hickson wrote:
No, we need more than that.
We need something that (in no particular order):
* introduces no new XSS attack vectors when a user changes client,
assuming the client is conforming to the new spec
* introduces no new XSS attack vectors when an author changes server,
assuming the server is conforming to the new spec
* can be implemented without changing the actual server software
* can be used to provide files for cross-domain access via GET without
scripting of any kind of the server side
* can be configured on a per-resource basis
* can be configured without coordination with the main site
administrator
* does not introduce the risk of caches inadvertently allowing access
when it should not be allowed
* leaves the control in the hand of the server
The currently proposed solution achieves all of this, by making the
server
make the decision, but requiring that the decision be conveyed using a
handshake that explicitly reports the decision, and making that
handshake
expressive enough that it can be precomputed and stored within the
resource itself, allowing it to be used without server-side scripting.
Your proposals so far have only achieved simplicity by not
addressing some
of the other requirements.
Has the working group gained consensus on this requirements list and
documented it?
--
Mark Nottingham [EMAIL PROTECTED]
