As said @agl, during registration, the result may contain an "AAGUID", which is basically the authenticator ID.
Interestingly, the specs mentions multiple times:
For example, the FIDO Metadata Service [FIDOMetadataService] provides one way to access such information.
If you dig enough in the spec and google searches, you'll end up with the giant JWT located here: https://mds.fidoalliance.org ...And, after parsing, you will end up with something like this: https://github.com/passwordless-id/webauthn/blob/main/src/authenticatorMetadata.ts ...it would be time for me to update that list.
Using that library, you can also directly extract the name of the authenticator. When playing around the playground you can see the parsed payload which may then look as follows.
{
"username": "Arnaud",
"credential": {
"id": "3924Hh...",
"publicKey": "MFkwEwY...",
"algorithm": "ES256"
},
"authenticator": {
...
"name": "Windows Hello Hardware Authenticator"
},
...
}
Please note that mapping the AAGUID to the name is a convenience function of the library, it's not in the raw data. Also, once again theory and reality clash. The latter "metadata services" contains lots of hardware authenticators mostly, while the community-driven project appears to be software authenticators mostly (a.k.a. password managers). In the end, both are lacking and you'll need a combination of both for the sake of completeness.
Last but not least, it's insufficient anyway. If you have three windows devices, it's useless to have three times "Windows Hello" as authenticator name. You still don't know which device it is. Although, for passkeys synced by password managers, that is enough since it's in the cloud anyway.
