WebDAV server, with plugable backend providers (filesystem backend up and running, CR backend in progress, personal project so it's moving slowly).
re the section of RFC 2617 you've quoted, A1 is defined in the simplest (non-session authentication) case in 188.8.131.52 as
A1 = unq(username-value) ":" unq(realm-value) ":" passwd
the last paragraph of 184.108.40.206 says that this allows the webserver to retrieve H(A1) from some other authentication source - although the webserver process (AOLServer in our case) need never see the cleartext password, somebody
on the server side needs to know it. So if you need to do Digest, but you don't want to trust your webserver to stay uncompromised, you could set up a (more trusted) auth server that the webserver contacts, saying "I have a request from bob in somerealm", the auth server looks up bob's password, calculates MD5("bob:somerealm:bobspassword") and passes the result back to the webserver.
Additionally, sect. 3.1.3 states
An optional header allows the server to specify the algorithm used to create the checksum or digest. By default the MD5 algorithm is used and that is the only algorithm described in this document.
so I wouldn't assume many clients implement H as being anything other than MD5.
While we could overcome this particular problem by defining a single authentication realm and storing the Digest-specific H(A1) value as the OACS password, this value is unsalted (which removes some of the security of using hashed passwords) and doesn't enable any of the other cases where a server side cleartext password is nescessary.
The other case I personally have come up against is an application that was primarily built on OACS but also provided LAN users with Samba-accessible shares - to keep the samba passwords in sync with OACS required patching ad_change_password, whereas I believe if PG contained passwords in clear we could have authenticated directly against it (although we never explored this avenue in depth).
Then there's the bloke who was wanting to authenticate IMAP clients against an OACS user list a month or so back, who was eventually recommended to patch ad_change_password to save out the passwords so he could plug them into his IMAP software (sorry, can't find the thread).