TL;DR there may be an issue with Chrome where it doesn’t allow you to authenticate using Internet Identity. If that’s the case, update, restart, and everything should be back to normal! You might also want to read on if you’re curious about how Internet Identity works internally.
Over the past week, we (the Internet Identity team) have received many support requests[1] related to authenticating with Internet Identity, i.e. when trying to login to dapps like NNS or Distrikt and by using your II anchor.
The symptoms are as follows: 
usually when you land on https://identity.ic0.app your browser offers to authenticate you using e.g. biometrics (Windows Hello, TouchID, etc), but one day 
it doesn’t and instead asks you to use a Yubikey or another USB device.
But don’t worry! So far, users who reported the issue have been able to fix the issue by upgrading the browser and/or restarting.
It appears to only happen in chrome; at the very least we have not been able to (“officially”) witness this in any other browser. All OSs seem affected equally (although we haven’t had a bug report yet from a Linux user, but there are generally fewer of them).
So what seems to be happening? Internet Identity, II for short, uses some of the WebAuthn APIs to create and use cryptographic material – but don’t run away yet. What this means is that there are effectively two calls that II can make to your browser: create and attest[2]. When II calls create, your browser creates a secret that gets stored in a secure module on your computer and returns the ID of that secret; the secret itself is never shared with II. This happens when you create an II anchor. Then, when you authenticate (for instance when logging to the NNS dapp) II will ask your browser for a proof that you are indeed yourself and that you have access to that “secret”. II gives your browser a document to attest and will also give the browser the ID of your secret. 
Let me stress this, you cannot simply look up those secrets, you need to know the ID. And this is seems to be where the issue lies.
It looks like, somehow, some users’ browsers have had issues with attest; in particular, it didn’t seem to find any secrets with the ID given by II. Instead of giving up just yet, the browser assumed that the user had stored the secrets somewhere else, for instance in a yubikey (that’s what happens when you register and anchor and use a yubikey instead of biometrics), prompting the user to insert one. Note: the symptoms did not mean that the secrets had been wiped, since restarting and/or upgrading the browser has so far always fixed the issue, meaning the secrets were still around; the browser just couldn’t find them (with the given ID).
All that being said, another possibility is that recent changes in II may have caused those IDs to be unusable in some cases. But given that the issue seems to only occur on Chrome, we believe that Chrome is the issue.
If you have thoughts, or if this has happened to you and you’d like to share details, please go ahead! Otherwise, upgrade your browser if you’re a chrome user, and happy ICing!
P.S.: Please save your recovery phrase somewhere! You never know, someday your browser might very well decide to wipe those secrets and you’ll be locked out.
-
Even on this very forum: Unable to login my Internet Identity Anchor to NNS dapps - #15 by nmattia ↩︎
-
In reality they are called
createandgetbutattestis clearer for the use that II makes of it. ↩︎