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.
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...).
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.
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.
Comments
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.
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...).
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.
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.