Usual authentication with Ethereum is done by signing with the private key, which in turn requires direct access to the private key. This is quite secure but inconvenient, since you need to have a web3 wallet holding your private key in every app in which you’d want to identify using Ethereum identity.
The DAuth proposal wanted to improve that by having a server do the authentication for you. A user could choose to set up its own server (otherwise, it would be a centralized authentication) and register that address in a smart contract (so that client app knows who to contact for id. But the auth server has to keep an unencrypted version of the private key. Client app sends a random encrypted string to the auth server, that decrypts it and sends it back, upon which client is happy and convinced. So unless you run your own server, you entrust your private key to a third party. Additionally that means that you can’t use this identity for payments (you wouldn’t trust your funds to be on that address).
Instead of a server signing a message, we’d want the client to sign a message. But the client doesn’t want to keep his private key (too long). So what if the secret is actually derived from the password, for example a hash salted with the public key: Hash256(password | pubkey). Now instead of proving ownership of a complex private key, Alice can identify herself by proving ownership of a key simple enough to remember. However then it becomes easy to brute force. Authentication servers don’t allow trying for millions of solutions per second, here all the information to brute force is available on-chain. If it’s easy enough to remember, it’s easy enough to brute force.
Hope it helps you to start brainstorming.