Is interesting idea. Reading about https://blog.cloudflare.com/opaque-oblivious-passwords/ reminded me that on this blog, there is no password to access the backend. It's a normalized practice for me that I don't even think about it. Pub/priv key only, so registration is manual. OPAQUE as a protocol to allow cleartext passwords to never leave the client is very interesting along with a typical registration method.
The one thing I need to figure out though is how OPAQUE works exactly in terms of identity. It looks to me that both the client and server need a public/private key meaning just like a crypto wallet, you need to back up the identity on the client and that is a weird step for most users. With a DID (digital identity), this step could be taken care of automatically.
This kind of pub/priv key stuff would work in an office setting with employees. Maybe there is something I'm missing on the client identity generation and storage part which to me makes it infeasible for a mass setting. The demo in the cloudflare has a random identity for the client. The golang rsa.GenerateKey function generates a random keypair to sign the password, sooo.
I guess it is telling when I can figure this stuff out from code I've never written extensively in before (golang, wasm).
The primary idea is to treat the server as untrusted, so that's why you send hash of a password to it to get it to prove its identity.
Anyway, I'll read more about how it works later. I've been more on the rage for just plain old SSO from third party providers like Google or using one of the best password encryption algos if a password is really needed. Delegating authentication to a third party is for the better.