The "ID" for this credential. For residential credentials, that lives on the Security Key, but without them the Security Key just mints a new random ID, plus a key pair each time it is told to enroll.
This ID is public, for practical reasons an OpenSSH client setup will store it in the same sort of place it would keep a (possibly encrypted) private key for normal public key crypto but it isn't actually private, you could for example put the file on a (HTTPS) web page you copy-paste from to configure every new device you get, if bad guys see it they don't learn how to sign in to GitHub as you.
The Security Key doesn't (without resident credentials) remember what this ID value is. On a web site, that ID value would get squirrelled away somewhere during enrollment by the site's backend together with the associated public key, maybe to a database table, and the site gives you a list of IDs after you tell it your username or whatever - when you try to use a Security Key, your Security Key can look at such a list and (using Authenticated Encryption) it can see it made this one, and from there rediscover the private key and use that to authenticate you.
But unless it is shown the ID it is clueless. No idea how to authenticate. If you've lost the ID, or maybe it's on a device you don't have access to at the moment, your Security Key can't help you.
Edited to add: Behind the scenes, the implementation at enrollment goes something like this, the Security Key mints the random keypair and then it uses its own permanent secret symmetric key (which never leaves the Security Key and is likely very hard to extract even in a lab setup) to encrypt the private key or some seed value and that encrypted value (which only this Security Key can decrypt) is used as the apparently random ID.
Oh yeah, I forgot to mention, the ID is not small. This is at least 16 bytes. And even devices that don't need to hide something inside that ID are forbidden from just using some boring counter or something that would be distinguishable, it has to look at least mostly "random" in that case (minimum 100 bits of entropy).
This ID is public, for practical reasons an OpenSSH client setup will store it in the same sort of place it would keep a (possibly encrypted) private key for normal public key crypto but it isn't actually private, you could for example put the file on a (HTTPS) web page you copy-paste from to configure every new device you get, if bad guys see it they don't learn how to sign in to GitHub as you.
The Security Key doesn't (without resident credentials) remember what this ID value is. On a web site, that ID value would get squirrelled away somewhere during enrollment by the site's backend together with the associated public key, maybe to a database table, and the site gives you a list of IDs after you tell it your username or whatever - when you try to use a Security Key, your Security Key can look at such a list and (using Authenticated Encryption) it can see it made this one, and from there rediscover the private key and use that to authenticate you.
But unless it is shown the ID it is clueless. No idea how to authenticate. If you've lost the ID, or maybe it's on a device you don't have access to at the moment, your Security Key can't help you.
Edited to add: Behind the scenes, the implementation at enrollment goes something like this, the Security Key mints the random keypair and then it uses its own permanent secret symmetric key (which never leaves the Security Key and is likely very hard to extract even in a lab setup) to encrypt the private key or some seed value and that encrypted value (which only this Security Key can decrypt) is used as the apparently random ID.
Oh yeah, I forgot to mention, the ID is not small. This is at least 16 bytes. And even devices that don't need to hide something inside that ID are forbidden from just using some boring counter or something that would be distinguishable, it has to look at least mostly "random" in that case (minimum 100 bits of entropy).