Note that in your example, the identity service would now know it's pornhub that you, John Doe, was trying to access. This could be sensitive information that you wouldn't want revealed. It would be better if the identity service creates a temporary token (say it lasts for 5 minutes) that pornhub anonymously queries so the service doesn't know it was pornhub that's trying to access it, but it would still know that you tried to create a token, and if the identity service logs the IPs it could figure out that it was pornhub.

A better system is an offline system, similar to how our digital COVID vaccination cards used by some US states (SMART Health Card system). You generate a public / private key pair, verifies it with the state who then signs the public key. You just need to present the signed public key to the porn site and then use the private key to prove that you own it. This is a bit more technically challenging to implement though as you are now asking people to manage public/private keys. Even then this system may still leak info since now you have a known public key that you are reusing as an identity across sites. Note that for vaccination cards this is not a problem because you just get a QR code which is a piece of signed information stating that your name/DOB is indeed vaccinated. For porn sites you want an anonymous way to identify yourself, not a public name.

To really be privacy-preserving you would need to use some form of zero-knowledge proof but now we are getting into really technical new technology territory.

I guess what I'm trying to say is, lawmakers always just claim there are ways to make this privacy preserving but none of the lawmakers who say this are computer scientists from what I have seen so far, and I don't trust the government system to actually be well thought out enough to be what I consider privacy preserving. It's just a word that people throw around without really thinking through the technical details, and it's actually not that easy to actually come up with a system that works.

I keep seeing responses like this but they never make sense to me.

Your argument basically boils down to "JS-based SRP is insecure because JavaScript crypto is insecure, which is because of the web page delivery mechanism". Well, yes, web crypto has a chicken and egg trust issue, but this problem *already exists in the current traditional login methods*! If a malicious actor can inject HTML/JS into your login page, *both* SRP and traditional password logins would both be hosed, since it would be trivial to just listen to all the keyboard inputs and query the password field's value.

Browser JS-based SRP can't defend against JS injection, but it defends against other things. It protects again careless mistake like the recent ones (Github and Twitter accidentally logging traffic). It also increases trust. In the traditional method, failures are silent. A malicious or incompetent actor could silently log all the passwords without you the user knowing about it. All you have is their word. For SRP though, an attack is much more visible and much less likely to be due to a coding error. Since it requires changing the login page's code and will send more information back, it's likely to be caught by security researchers unless it's a *really* targeted attack.

SRP also protects against MITM attacks. These are not theoretical. Look up BEAST/CRIME/BREACH which were attacks on TLS protocol itself, or Cloudbleed (https://en.wikipedia.org/wiki/Cloudbleed) where CloudFlare had a bug in their SSL proxy which led to anyone being able to intercepts their SSL traffic (incidentally 1Password traffic was intercepted too but was fine because they used SRP...). These kinds of attacks are passive MITM listening attacks, and a browser-based SRP would still be fine since the attacker isn't injecting content.

Browser SRP is not perfect, but it doesn't need to be! It just needs to be *better* than traditional password entries. In this case it's actually *strictly* better, since all the failure cases for SRP are also failure cases for traditional passwords.

I do agree a native browser SRP solution rather than one based on JS would be nice, but perfect is the enemy of good. JS-based SRP is already better than traditional login pages, and if you build a website you can already deploy it.

"All this to solve a problem that the wider community generally considers 'solved'"

Well...as we can see from these two instances it's clearly not solved. Defense in depth means you reduces risks in multiple layers. Also, as I mentioned, we are thinking on the side of server administrators. Even if you claim you are practicing good security practices, there's no way for a user to know as he's just sending the raw password to you anyway. If you use SRP though, I can actually hold you accountable since I know there's literally no way for you to steal my passwords. It's like in SSH where I know it's literally impossible for the server to steal my private key.