FIDO2 can optionally support "usernameless" login. After enrolling, your authenticator can keep all the details it needs to authenticate you somewhere, and then "logging in" becomes go to the right site and use your fingerprint or whatever on the authenticator. No step where you type in an email address or anything like that, you are you and your authenticator knows exactly who that is.
With FIDO1 nothing lives on the authenticator. If I drop my authenticator on the subway, and you find it, unless you somehow guess my identity and try to log in as me, the authenticator gives you no clue (I mean if I wrote my name on it in Sharpie that would tell you, but the technology itself doesn't) and you can just use that authenticator, might as well, free authenticator. Probably a bad idea if you're Edward Snowden but for Mr Average it's safe.
But with FIDO2 your actual credentials can live on the authenticator, which means it knows (in some sense) who you are. On the other hand this mode should be protected with a second factor (since the authenticator itself is no longer the second factor) such as a fingerprint sensor, or maybe a PIN lock.
You got the effect of FIDO1 right, but the mechanism is a bit cleverer. On a cheap device this is relying on Authenticated Encryption. When a site says "Prove you're still you" to a FIDO1 authenticator it needs to provide a huge "Identifier". Well, for the cheap devices (maybe not an iPhone, but say a Yubikey) that "identifier" isn't really just a very large index into a table, they've only got a tiny amount of flash. Instead it's actually your private key for that website encrypted by the authenticator using its own symmetric key, and the AE is used to confirm it is the correct website. If it wasn't the key doesn't decrypt and that's exactly the same scenario as if you plugged in the wrong authenticator, a thing people do all the time.
From the authenticator's point of view, suppose you've got a nice red authenticator and also a blue one. You have enrolled the blue one at Facebook but not the red. Let's see three scenarios
1a. You forget and try to use the red authenticator to sign in to the real Facebook
1b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook
1c. Your red token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... No.
1d. Your browser says nope, try a different token?
2a. You are being phished and try to use the blue authenticator to sign in to Fakebook
2b. Fakebook sends over the identifier from the real Facebook site, some-huge-ID-made-by-the-blue-token-for-Facebook
2c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for fakebook.com, the Authentication Encryption says... No.
2d. Your browser says nope, try a different token?
3a. This time you remembered to use the blue authenticator to sign in to the real Facebook
3b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook
3c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... Yes.
3d. Your token can sign an "I'm still me" message for Facebook using the Private Key it got back with the Authenticated Encryption. You get into Facebook.
To support all this, the remote sites should keep a list of up to say half a dozen authenticators you've enrolled, and it should hand over the full list on each sign-in. "Do you have any of these?". Your browser polls each authenticator with each ID, "Hey, authenticator, is this one yours?" if any of them say Yes, we're done, proof provided. Otherwise, tell the user none of the tokens worked, do they have others?
For enrollment a similar strategy is used. The site hands over all the IDs it already has and the browser says "Hey, do you recognise these IDs?" if an authenticator recognises one of the IDs then we enrolled that one already, look for one that doesn't recognise any IDs, that one should be enrolled.
With FIDO1 nothing lives on the authenticator. If I drop my authenticator on the subway, and you find it, unless you somehow guess my identity and try to log in as me, the authenticator gives you no clue (I mean if I wrote my name on it in Sharpie that would tell you, but the technology itself doesn't) and you can just use that authenticator, might as well, free authenticator. Probably a bad idea if you're Edward Snowden but for Mr Average it's safe.
But with FIDO2 your actual credentials can live on the authenticator, which means it knows (in some sense) who you are. On the other hand this mode should be protected with a second factor (since the authenticator itself is no longer the second factor) such as a fingerprint sensor, or maybe a PIN lock.
You got the effect of FIDO1 right, but the mechanism is a bit cleverer. On a cheap device this is relying on Authenticated Encryption. When a site says "Prove you're still you" to a FIDO1 authenticator it needs to provide a huge "Identifier". Well, for the cheap devices (maybe not an iPhone, but say a Yubikey) that "identifier" isn't really just a very large index into a table, they've only got a tiny amount of flash. Instead it's actually your private key for that website encrypted by the authenticator using its own symmetric key, and the AE is used to confirm it is the correct website. If it wasn't the key doesn't decrypt and that's exactly the same scenario as if you plugged in the wrong authenticator, a thing people do all the time.
From the authenticator's point of view, suppose you've got a nice red authenticator and also a blue one. You have enrolled the blue one at Facebook but not the red. Let's see three scenarios
1a. You forget and try to use the red authenticator to sign in to the real Facebook
1b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook
1c. Your red token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... No.
1d. Your browser says nope, try a different token?
2a. You are being phished and try to use the blue authenticator to sign in to Fakebook
2b. Fakebook sends over the identifier from the real Facebook site, some-huge-ID-made-by-the-blue-token-for-Facebook
2c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for fakebook.com, the Authentication Encryption says... No.
2d. Your browser says nope, try a different token?
3a. This time you remembered to use the blue authenticator to sign in to the real Facebook
3b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook
3c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... Yes.
3d. Your token can sign an "I'm still me" message for Facebook using the Private Key it got back with the Authenticated Encryption. You get into Facebook.
To support all this, the remote sites should keep a list of up to say half a dozen authenticators you've enrolled, and it should hand over the full list on each sign-in. "Do you have any of these?". Your browser polls each authenticator with each ID, "Hey, authenticator, is this one yours?" if any of them say Yes, we're done, proof provided. Otherwise, tell the user none of the tokens worked, do they have others?
For enrollment a similar strategy is used. The site hands over all the IDs it already has and the browser says "Hey, do you recognise these IDs?" if an authenticator recognises one of the IDs then we enrolled that one already, look for one that doesn't recognise any IDs, that one should be enrolled.