Is it possible to use Digest-Authentication with a XMLHTTPRequest?

You can do it no problem. Just follow the parts of the specs you feel like ;)
http://tools.ietf.org/html/rfc2617
and is all you are missing to start writing your authentication library
http://pajhome.org.uk/crypt/md5/
on the client side.

pre-exchange user name and password
Hey I want to authenticate ----> server
Ok here is a nonce/salt ----> client
here is a md5 hash sum of my username password timestamp and the salt -----> server
I just hased up your password and username the same way you did and they are the same ----->client
Those are the basics of it.

I left out that you need to include the URI of the requested resource in the hashsum!!!!
Of course you do this with every request you make for a resource to the server that way some one intercepting the hash could only view the content you requested and could not make a request for a miscellaneous resource.This method does not secure the data just access to it.

Have a look at this article : https://web.archive.org/web/20130227152456/http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/. It explains how to do JavaScript client for Digest Authentication with SpringSecurity in the server side. The code is available in github : https://github.com/Arrowgroup/JSDigestAuth

I have coded a full workflow for this, it's not difficult at all once you are using an external library for MD5 (I use Crypto-js).

The greatest issue you might have is that on the first server 401 reply any of the most used browsers will open a dialog box for getting your credentials. As far as I have seen there is not easy way to circumvent this: How can I supress the browser's authentication dialog?

To solve it, I modified the webserver which I coded from a C# codeplex project. On the first request the client passes a "Warning" header saying "Do not raise a 401". The server creates the challenge and sends it back with a custom, non-401 HttpException (I use 406 for the moment, which is "not acceptable" in HTTP). The client creates the hash and sends it back.

I can post some code snippets if anyone's interested, this is kind of an old question.