SQRL isn't able to square the circle on Phishing. The exact formula changes (the document you linked was last updated this month though SQRL started many years ago) but this remains true.

The idea in SQRL is that surely if we show the user what they're about to do (e.g. sign into mybank.example), they'll realise they're being phished (e.g. by "notmybank.example") and abort. But the whole _point_ of phishing is that humans don't work that way.

In one of Microsoft's early experiments with this stuff they asked users to put their own _real_ bank credentials into obviously bogus sites with a variety of warning conditions to try to understand what's effective. _Nothing_ was effective, ordinary users click past the warnings of imminent doom in order to complete the task. I've written here before about "Brick Wall UX" the practice of designing security systems where there is no way to press on into danger. The reason for Brick Wall UX is that it _works_ and that's what WebAuthn/ U2F deliver for phishing.

In other respects SQRL isn't much different than other 2FA options like TOTP, although it has more moving parts. But because it can't fix phishing, it's not worth another look, if you decide phishing isn't scary enough to warrant extra work, TOTP already exists. If TOTP isn't good enough because you're (not unreasonably) scared of phishing, buy some Security Keys and do WebAuthn.

I've done research on this, and I'm working on a SQRL alternative. The solution we came up with is an optional browser addon. Websites tag their QR codes as 2FA codes via HTML, the addon captures it and validates against the expected domain (HTTPS assumed), and if it matches then the QR code is promoted as part of the browser's UI or even sent directly to the phone.

The goal is to automate away the domain verification. Since the addon doesn't have to know any secrets, it should be installed in as many devices as possible and eventually be included in the browser itself.

Also note TOTP is not an equivalent alternative because it has terrible UX in migration/restoration/revocation scenarios.

WebAuthn is only secure because it entrusts to browser to pass verified domains to your USB key. Why can't SQRL just do that with no other protocol modifications? Then we don't trust the user with anything, protocol-wise. Cause sure, if the site can pass a QR code or URL directly everytime, that's an issue because you're still trusting the user to manually verify the domain, but if the interaction is mitigated by a trusted party (i.e. the browser), then I don't see the problem.

Technically the FIDO device ("USB key") doesn't get told the domain name. The browser throws it into a compression function with the random values and a bunch of other stuff to compute a value the server also will be able to calculate for itself. Your key has no idea what facebook.com is, doesn't care.

The FIDO device is impressively dumb on purpose, makes it hard to attack. Given an input and a hardware user interaction it responds, cheap ones aren't storing anything or doing any conditional work, and the interaction means you can't do any sort of brute force attack - if you somehow RCE the browser and prompt the user "please press the button a million times" they're going to report that as a bug and close the browser.