You do realise that with XDR, 'resource host' has no means to
authenticate the user using (relatively secure) HTTP digest
authentication?
I both realize and support XDR's decision to not transmit the user's HTTP
auth credentials. These credentials are semantically equivalent to the use
of cookies described and attacked in the references cited above.
These attacks have been proven to not be the fault of cookies. Therefore it
makes sense that auth credentials would also not create such attack vectors.
As an aside, HTTP digest authentication is no more secure than
transmission of a plaintext password. The space of user passwords is so
small that a brute force attack against a password hash is feasible.
What does this have to do with the HTTP digest authentication? The digest
authentication provides a secure of way transmitting passwords. You protect
against brute force attack with attempt limitations, not password
encryption. If you don't use such measures it doesn't matter you how you
encrypt your passwords, you will still be prone.
In order to acquire the desired functionality (for which it needs the
user's credentials), with XDR the resource host will most
likely end up
passing the authentication information along in the GET query string
(bad), probably requiring the user to fill in his credentials on the
origin site (bad), and sending the user's password plain over
the wire
(bad).
Since general understanding of application security is so muddled and
incomplete, I have no doubt that many developers will choose to have their
users give their credentials to third-party sites.
What a depressing outlook for the future. Developers are stupid, so we will
make sure they can't use real security measures because they are more
complex. The reality is developers been pushing the limits of what they can
do securely on the web. Web developers are more than capable of using real
measures like OAuth to authorization, if they are given adequate mechanism
for doing so.
breaking of REST by disallowing PUT and DELETE and setting the
Content-Type and Accept-* headers, while favouring SOAP
I characterize the web-apps that I develop as being RESTful, and don't see
any compelling value proposition in the various SOAP related
specifications. The XDR proposal adequately supports all of the
programming patterns that I find useful in a RESTful web browser
application.
Yeah, it seems quite trendy to call your web services RESTful even if you
never use PUT and DELETE. True read/write RESTful services on the web are
heavily dependent on PUT and DELETE.
The XDR proposal does not introduce any new limitations that we must abide
by in creating web applications, and so cannot be said to break anything.
It certainly doesn't break anything existing, but it does attempt to take
allow cross-site communication, such comunication will have fundamental
semantics broken which could have enabled powerful interoperability.
That the XDR proposal enables cross-domain requests with minimal
complexity and in a way which is unlikely to cause IT administrators to
disable the feature, is, in my opinion, reason enough to be enthusiastic.
The XDR proposal seems like something that could be a stable platform on
which to start building new kinds of applications.
I actually really appreciate the effort to make things more simpler.
However, I do not understand how creating a new API, and creating a new set
of headers is going to make things simpler. The code necessary to deal with
the new APIs is certainly going to impose a burden on developers. If
simplicity is really goal of IE, why not work with W3C on simplifying the
current proposal? Most of the differences are completely orthogonal to
simplicity like header names, and the JS API. One could easily just subset
the W3C/CS proposal to the level of simplicity of XDR.
Kris
