It was too early, but also lingered in development for far too long. It also never had the proper server-side implementations, so it could feel like a solution in search of a problem.<p>That said, the design is far more advanced than the rolling disaster which is Passkey and it is much better suited for small Yubikey-type devices, where you could easily have unlimited site support. It also had intrinsic portability and advanced real-world security considerations, such as an attestation that instructed a server to disable weaker authentication methods, such as email or SMS (which is also a customer support disaster, but still...).<p>Ultimately, SQRL is an object lesson that the best technical design doesn't always win - it needs the right timing and robust community/corporate support.<p>Edit: Also, the (client) reference implementation was written in x86 assembly language for Windows. So I'd say the timing, support, and portability are all reasons for the lack of adoption.
SQRL has the same weakness as passkeys: secrets on device are too easily lost, gatekeepers too greedy to solve that without taking away user sovereignty, and people don't understand it.<p>IMO both solutions are a lost cause. Hopefully I'm just cynical and something can be worked out.
Discord and Steam have a user login flow that is very similar to what SQRL was aiming for, including a QR code alongside the username/password fields. While it's a closed implementation of a different system, I think of SQRL every time I use it.<p>I might be biased, I used the PPP Pam module on linux for years, until I moved to TOTP, and then eventually to pubkey-only.
eh. it’s cool,<p>but compared to FIDO which existed when it was made, it’s pretty obviously “wrong”.