[fzzt]

There's a lot more to that. A bank doesn't want the "back" button to work forever; they want to control the lifetime of your session, ideally on the server. Google wants to let you sign into multiple accounts on the same origin. Many others want to have seamless single sign-on across several of their web properties. Sometimes, you want the change of your password to invalidate other sessions (say, when recovering a compromised account); other times, you don't want to kick out your smart thermostat and have to set it up from scratch.

Admittedly, there are some simple use cases where HTTP auth is all you need, but it's just way too inflexible, unless you turn it into some mammoth spec that is never going to be as flexible and tempting as managing user identity yourself.

Especially since HTTP auth doesn't actually mean you can stop doing that anyway. You're still handling account creation, password checking, all the abuse / bot detection bits... all you're getting rid of is the sign-on and logout functionality, which is really not that complicated to begin with.

[madacol]

Maybe we don't want them to be able to do any of that

And I think you are missing the point, the goal it's not to standardize logins, it's about making impossible for servers to know my password, hence impossible passwords leaks

That would allow people to reuse strong passwords, and not need passwords managers, because that's what they are doing anyway!

[fzzt]

> Maybe we don't want them to be able to do any of that

"We" who? Application owners want that, browser vendors want that (their greatest fear is that mobile will eat the web, so they don't want to make the platform less flexible)... and users generally don't mind.

> impossible for servers to know my password, hence impossible passwords leaks

That would require deeper architectural changes to HTTP auth, but is probably a reasonable goal. That said, it's more readily approximated with unique passwords + having a good password manager. The main risk of password leaks is not that they make that particular breach worse (since the attackers can just grab your data), but that passwords are reused too often.

Federated login is another approximation, where the password is only known to your identity provider, not to every identity consumer. It's modestly successful for some lower-value services.

[madacol]

We = users *

[alerighi]

Depends if that is required. For most enterprise software, that nowadays is more and more web based, you don't need all of that. Accounts are created by the system administrator, the password check is fine with the default mechanism of Nginx or Apache with a .htpasswd file, bot detection and all other things are not really that necessary, especially if the page is not exposed to the internet but only in a LAN.

Beside that, if you need a more sophisticated authentication mechanism nowadays your default is to go with something that uses the Oauth protocol: so I guess the next step would be to standardize that protocol and have it integrated as a browser API so that a user doesn't even have to insert a password.