> Maybe <input type=password-pake algo=opaque> rather than type=password.

That's not how OPAQUE (or similar things) works. You cannot, in fact, just drop this in and "slowly" change. You need an enrolment step where the server does not learn the password (but does end up able to ascertain whether the client knows the password), and from then on all clients must not reveal the password to the server. The sign-in process now needs a phase where the client has identified itself in order to receive parameters it will need to deliver live proof of having the credentials, so that means re-designing many single-step sign-in processes (e.g. username and password on same form)

And all the hard work is destroyed the moment either the user types their password in to a conventional web form, anywhere, or the server ends up actually storing passwords and not OPAQUE's "envelope" data, both of which are almost certain to occur if you try to introduce this "slowly".

You are assuming a lot about the implementation that I didn't specify. I'm also not saying that I have fully designed the API for this, just giving a very rough idea of what it could look like.

> You need an enrolment step where the server does not learn the password

Of course, there would be something similar to new-password that can be used on password set and change forms that would do the enrollment dance.

> The sign-in process now needs a phase where the client has identified itself in order to receive parameters it will need to deliver live proof of having the credentials, so that means re-designing many single-step sign-in processes (e.g. username and password on same form)

IIUC the browser could get the user id and password in one step then do the back-and-forth with the server afterwards.

> both of which are almost certain to occur if you try to introduce this "slowly".

I don't see why this is certain to happen. For passwords that use OPAQUE the password manager would set a flag that prevents it from being filled into any field that is accessible to the website. In practice this means that it would refuse to fill in any input that isn't `type=password-pake` and the value of that input wouldn't be accessible to the site. For the user to work around this they would need to copy-paste or retype the password themselves. It won't stop everyone but there is lots of room for good UX warnings.

But again, I'm not claiming that I have designed the perfect protocol, but I think passwords have value because they can easily be typed, written down and re-imported by users whereas most key systems make this very difficult (although maybe shorter keys and more efficient encodings can mitigate this). The ability to pick your own password is also valuable for the few passwords that you do need to memorize. My point is that I think that there are significant upsides to passwords and most of the downsides can be worked around such that users would barely notice the difference.

> My point is that I think that there are significant upsides to passwords and most of the downsides can be worked around such that users would barely notice the difference.

That's barely a "point" and more an abstract notion that you're correct although you're aware the evidence suggests otherwise. The supposed "strengths" of passwords are in tension with any attempts, like yours, to make them actually useful for authentication. We have something that actually works, today, WebAuthn. If you care about the authentication problem use WebAuthn.

Maybe I haven't seen a good implementation but I wouldn't say WebAuthn works. I have yet to seen a version that syncs across devices which is a fundamental requirement for me. I'm also not sure how I can type in a WebAuthn credential to someone else's computer or how I can memorize it so that I can use it when I am away from my phone+computer.

Both approaches clearly have gaps right now, all I am saying is that long term I think the password+PAKE looks more promising than what WebAuthn offers.