The reason I suggested FHE might change this was the a few of the solutions people have tried so far fall into the so-called "white box cryptography," bucket of key based obfuscators on your mobile/endpoint device. Depending on the authentication scheme or security protocol, you need a secure place to store your private key, a shared or derived secret, key encryption keys, or a certificate, etc. We have to assume that the OS of that client device is going to get rooted at some point and the security of those keys is gone - and with it, the identity assurance they provided. (again, the secure element and diversified initialization keys on apple devices is different, think of it as a little client side hsm)
Instead of using WBC, in this hypothetical case FHE becomes the scheme for performing a verification step without yielding information about the key to an attacker with root on the device. It's another handwavey blackbox, but it's a such a change in how we do security protocols that it's worth mentioning as plausibly having consequences for authN. It's a hard problem that gets addressed in areas like authenticated encryption, direct anonymous attestation, and other more use case specific protocols. Someone working in the field today would have more insight into it.
Hmm, I was asking as a few days back the IBM FHE release provoked me to ask what were the use cases for FHE? This seems to be, tantalisingly, the most interesting so far.
If FHE has a practical internal xor operation, the idea of iterating a key and diversification component/counter, e.g. like a FHE implementation of HOTP or OCRA becomes really interesting. Even if it's slow, you could probably stack the slow operations into the initialization/personalization phases.
Security and authN protocols are really just about using crypto to diffuse and distribute risk, so it's conceivable there are use cases where FHE facilitates shifting risk for key security onto the end user, like payment cards, etc.
So, just checking in case I am being dumb, HOTP (like TOTP) works where both parties have shared secret key (common in corporate remote logins).
The value here being that I can make my own secret key, and via FHE send the server a "cloaked" key that they will get the right answer without knowing my secret.
So apart from the initial key sharing, it's down to me to keep the key safe (as you say, pushing risk into the consumer like debit cards)
Instead of using WBC, in this hypothetical case FHE becomes the scheme for performing a verification step without yielding information about the key to an attacker with root on the device. It's another handwavey blackbox, but it's a such a change in how we do security protocols that it's worth mentioning as plausibly having consequences for authN. It's a hard problem that gets addressed in areas like authenticated encryption, direct anonymous attestation, and other more use case specific protocols. Someone working in the field today would have more insight into it.