This is indeed very simple. But I'm afraid this will evoke what I call the "crypto gag reflex" which in this case would be, "client-side javascript + crypto === BAD."
How do you respond to this criticism? Is it valid in this case?
It's a very valid criticism, and it's the main reason that DSSID is not quite ready for prime time. I'm participating in a W3C working group trying to develop new browser standards that would allow secure client-side crypto with a better UI than client certificates. It's a very hard problem.
But even in its present state I would argue that DSSID is at least as secure, and probably a great deal more secure, than any other extant authentication scheme out there. If you trust SSL, trust the DSSID server to be secure against write attacks (i.e. attacks that allow a hacker to change the content being served), and pay attention to the URL in your browser bar before entering your pass phrase, then DSSID is secure. (There's actually one other vulnerability, and that is malicious plug-ins, but no software-based security scheme can possibly be secure against that.)
By way of contrast, with passwords, you have to trust EVERY SINGLE SITE that you log in to. You have to trust the certificate chain for every single site that you log in to. (With DSSID you only have to trust the certificate chain for your DSSID server.) You have to trust that every single site that you log in to has not had malicious Javascript injected. You have to pay attention to the URL of every single site you log in to, not just one.
Most problematically, many HTTPS sites do not have valid certificates, which trains users to ignore warnings about invalid certificates, which essentially undermines ALL of the security of SSL. So having to only ever trust one certificate (which will always be valid) is a huge win.
If DSSID were be broadly adopted it would become more secure. Once the code is stable enough, I am going to open-source the DSSID server code so that anyone can run their own DSSID server if they don't trust mine. The Javascript that is served from the DSSID server is static (except for the nonce) so it can be independently audited and verified. The DSSID protocol doesn't have to implemented in Javascript. You could write a plugin that implemented it, or build the capability into a browser. It's a lot easier to plug the holes in DSSID than anything else out there.
How do you respond to this criticism? Is it valid in this case?