I still cannot understand why mutual TLS never took off anywhere besides Gov [1].

You know how much more convenient it is to just open a browser and go to a webpage and already be logged in?

[1]: https://en.wikipedia.org/wiki/Common_Access_Card

Wouldn't that broadcast a stable identifier to every site you visit?

Isn't that desirable?

Safari (Apple), IE/Edge (Microsoft), and Chrome (Google) all operate their own ad networks. I'm sure they'd love their own version of X-UIDH [1].

[1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

that's precisely why it's not desireble

Mutual TLS was necessary but a giant pain in the butt for an app I worked on that needed to do over the air updates over WiFi. Getting it working across all of the moving parts was a significant part of the overall effort for the OTA part of that project.

OCSP existed back then which helped but I don’t know if stapling had been widely implemented yet.

The password isn't leaked, a hash of the salted and peppered password is the only thing in the database (+ the salt, and the pepper elsewhere).

Assuming it's implemented that way. Which is a big assumption.

As the main post was written in the voice of a knowledgeable developer picking a login flow, I assumed so indeed.

Yes, I deliberately didn't say it was _exactly_ a long password. I was more trying to get across the single-factor side of it.

In any case, if the service handles passwords properly and the user generates one password per service (both wild far-out concepts unfortunately), leaking the salted hash would not matter.

Agreed, but it’s nice to not have to trust a service to handle passwords correctly