It's definitely not stateless in terms of web sessions. To implement it you'd need a cache of recently-validated nonces, which actually opens up an attack vecto

It's definitely not stateless in terms of web sessions. To implement it you'd need a cache of recently-validated nonces, which actually opens up an attack vector as far as I can tell: 1. User reaches login page ~~~ attacker MITMs the nonce (the hard part) ~~~ 2. Scan QR, validate that nonce with a POST from the app. It's now in the cache waiting for the login page to follow through. ~~~ attacker hits login button with the same nonce ~~~ 3. User hits the login button, and depending on implementation, is either denied access as nonce has been deleted from the cache, or logs in and doesn't notice the attacker at all. This is, incidentally, exactly what FIDO U2F was designed to avoid. Using a token generator has this problem, where MITM-ing the 6-digit code gives an attacker a <30 second window to log in. On the other hand, FIDO U2F is actually stateless, and the challenge nonce and its validity never has to be kept in a cache at all. You just send back the challenge with the signed response, and if your device did it, great. What's more, FIDO prevents MITM attacks that attempt to intermediate your session by showing you a different TLS certificate, by ensuring that the server's TLS channel ID is the same as the one seen in the browser. SQRL cannot do this.