SQRL is a half measure, like SMS-TOTP it barely raises the bar because it doesn't solve a key real problem we actually see happening in the wild and so that would just happen more.
If site A is protected by SQRL, and I'm a bad guy, I can just live phish sign-ins for site A using SQRL from my phishing site, site B. The users all believe (as with other phishing attacks) that they're being asked for credentials by a legitimate site and so they provide them with SQRL, and I'm in.
This (very common and fully automatable) trick doens't work on WebAuthn, completely defeating phishing. This is because the fundamental idea in phishing is "Humans are idiots, fool the human into mistaking site A for site B". In WebAuthn the credentials are mechanically derived from the site you're on, so for site A they will always be site A credentials, and for site B, site B credentials. Convincing page design, an urgent email "from the boss", clever use of IDNs to fake the URL, those fool the human but not the machine, and the human is taken out of the "what site is this?" decision by WebAuthn.
But the human is left _in_ the loop in another way that leverages our strengths. WebAuthn requires a physical interaction, typically a button press by the human. So a hypothetical attack that takes say, 50 million authentications, cannot work because the human will not press the button 50 million times while you do the attack. They'll get sick of it and go on Twitter to moan instead.
Nope. SQRL assumes that phishing simply won't work. Users are going to be shown example.com and realise that's not right and abort. That's their "protection". But phishing does work, people have tested. Some users notice the ___domain name is wrong. Some don't. All press on anyway.
Why? Because Humans have a psychological problem that makes them bad at giving up. We need to explicitly train safety critical people to go "Oh, this isn't working. I will now report that I failed" rather than keep trying. In normal people the drive to press on is almost unstoppable.
Hence "brick wall UI" design for things like HSTS. If you give humans two options, destroy everything versus admit defeat, they pick destroy everything, every single time. So we changed the UI to not have options. "Defeat" announces the UI. And, defeated, the human gives up and doesn't destroy everything. Hooray.
SQRL does not give the real identity to a phishing site. Full stop.
Now a phishing site can do a fake SQRL login, accepting any credentials. But the client will send a different identity (derived keypair) with no information linking to the real identity, so the phisher will have no information with which to persinalize their fake site.
The user might press on anyway and divulge some sensitive data if the fake site is really convincing. But the phisher cannot use any credentials passed to them against the “real” site.
WebAuthn does NOT solve this “look-like site exists and accepts any credentials” problem either, nor does any other authentication mechanism.
The only protection against against what you describe is preventing registration of look-alike ___domain names entirely, and ensuring all DNS is secured with DNSsec or TLS. Good luck with that; it’s been tried.
I wish a larger conglomerate would steal the idea and implement it. I don’t like having to carry some physical hardware to login to some website. And the stateless nature of sqrl makes it quite easy to syncing logins on multiple devices without having to rely (or trust) on a third party.
What Brian_K_White is referring to is SQRL by Steve Gibson from GRC. https://en.wikipedia.org/wiki/SQRL.
Its an alternative simpler secure protocol that has been in development for a few years that is frequently discussed on the Security Now podcast.