Functionally that's what it sounds like they've done with their offline mode. They use "wave" style images instead of qr codes. They also use asymmetric crypto I think, like FIDO, but unlike OTP. It might not be feasible to offer a 6-digit code fallback, though, unless you can map RSA or ECDSA or whatever they're using into a problem with a 20-bit solution space without allowing offline brute forcing.
Their offline mode seems like FIDO but with a bidirectional wave image / camera requirement to get around lack of a better data channel (like u2f-hid support that FIDO requires).
> It might not be feasible to offer a 6-digit code fallback, though, unless you can map RSA or ECDSA or whatever they're using into a problem with a 20-bit solution space without allowing offline brute forcing.
Probably not. Supporting traditional (T)OTP is more about interop than anything else (the back-end just gets a one-time code to check against a list/counter or against a time-derived token, checking for drift etc. Main point is you can keep your auth-stack as-is, and your shared totp-secret in the same place[t]).
You could probably do assymetric crypto fine with qr-codes[1] they pack a lot of data.
If an ECDSA signature is ~48 bytes[2] -- that's going to be hard to compact down to a reasonable fallback... maybe. If the idea is to use asymmetric crypto as a backing for OTP, I suppose you'd do something like signing TIME+salt, and transmit the signature and the salt. Unless there is some trick one can do with checking partial asymmetric signatures, I don't see how you could get away with sending less than SIG+salt, or ~50 bytes. That's way too long for typing in, as a usable fall-back.
It might actually involve less typing to generate a shared secret -- but that'd completely break the UX -- so it doesn't sound like a sane fall-back to me.
Their offline mode seems like FIDO but with a bidirectional wave image / camera requirement to get around lack of a better data channel (like u2f-hid support that FIDO requires).