[mjec]

> HTTP got basic auth, which is crap because plaintext password transmission happens...

Plaintext submission happens with HTML forms too. The problem with Basic is the password goes with every request. That means you're exposing a long term credential to a higher risk. We want to exchange the long term credential for a short term one, ideally scope limited. That is far less catastrophic to revoke, and gives you some power of granularity (you can at the very least have some operations prompt for the password again). It also means you can limit risk on the server: only one page has access to the long term credentials, which can be more easily audited, or even hosted on dedicated servers.

WebAuthn has been the real savior here. Real cryptography has always been desirable for this, and removing per-site passwords is honestly just a bonus.

[c4mpute]

Imho WebAuthn is just the next problematic non-solution: Everything you do in WebAuthn you have to build up manually within the already-problematic forms+cookies+serverlogic+javascript stack. You cannot just instruct your webserver to do WebAuthn for /secret and everything works, no, you need tons and tons of code for it to work. Code that will have errors and problems. Code that is lots of complications on top of forms+cookies+serverlogic+javascript.

WebAuthn might solve a problem for the likes of Google and Facebook. But definitely not for the average web developer or server admin. And not for the user of some HTTP-based API. And the problem WebAuthn solves isn't really "we need better Auth", it is rather "we need better customer lock-in". Because the complexity and incompatibility of WebAuthn will just reproduce the debacle that was OpenID, only with the added "bonus" of being coupled to some hardware.