Same issue when I testing on webauthn.io with username test, but when I test it with a rather unique username, the problem not appear. Plus Yubico Demo Website has no problem with the username Yubico demo user as it always uses, so I will rather consider this a website-specific issue.
@flumm I tested this with solokeys and was able to see the same issue. OnlyKey uses the solokeys implementation of FIDO2 here solo/fido2 at master · solokeys/solo · GitHub
That FIDO2 implementation is certified but there are still differences from things like Yubikey such as how the key deals with duplicate registrations.
ok, just to clarify, the problem i initially had was with the webui of proxmox backup server (which supports webauthn).
on there i can register a yubikey (i borrowed one shortly from a colleague) multiple times and login always worked without problems but not with onlykey. i then tried to replicate it on webauthn.io (for testing) and assumed it was the same problem…
i’ll test some more next week since it seems the issue is something else
Some services restrict to only allow keys from certain vendors. For example, Vanguard.com supports only Yubikey, all other security keys are not permitted. For Azure AD, a handful of vendors are approved however any vendor key can be used by disabling ‘Enforce Attestation’ more info on that here - Error adding Yubikey to Security Info - Microsoft Q&A
There may be a similar setting in the server you are using. Another thing to try would be to use a different browser such as Firefox to register the security key. Let me know if that works, if it does there is a possibly related issue here - Cannot register to Microsoft Account - #13 by t11
I am one of the devs of proxmox and just wondered if we do something wrong. We do not enforce any vendor (at least not intentionally). It may have to do with the rust library for webauthn though. It is not so important since registering a key twice is not really a “normal” use case anyway and it works if I register it once.
Nonetheless I’ll investigate next week and report my findings (if you want)
the key i borrowed from a colleague was a yubikey 4, so it is not a fido2 key only u2f (afaics from the yubikey spec sheet) in contrast to the onlykey/yubikey 5. so my guess is that the fido2 implementation of chrome/chromium is at fault here.
our fix is to include the already registered devices in the excludeCredentials option on register, that
way, chromium shows the user that this key is already registered
i did some further investigation into this (since we now tested a yubikey 5 succesfully) and it seems that the token sets numberOfCredentials in the assertion response but not a user identification list
there is already an open chromium bug[0], but i did not find the mentioned ctap2 pr
afaict, the spec[1], says this is ok but it is not completely clear to me
