When I add my vivokey using the latest applet
to my Google account it doesn’t recognize it as a normal fido2 device. From what I understand it is seeing it as a u2f device instead as seen with the “This key can only be used with a password.” Meaning it doesn’t work for passwordless logging only as a 2fa method.
Is this a known issue with Google? I’m using Firefox and I have tried via android and windows reads.
How did you add the key to the Google account, and which device and browser did you use? Google still differentiates between second-factor and single-factor (Passkey) credentials, see VivoKey releases NFC Passkey Manager - #7 by StarGate01 . Try adding the chip as a Passkey.
There are still so many confusing ways websites and services implement FIDO.. but generally speaking, as of today, most websites will let you add a FIDO token as a “security key” and a “passkey”.
This is really interesting. I have two devices right now I have been using my passkeys without issue. My android phone and my windows computer. I’m still waiting on a fully compatible NFC reader to arrive for my linux work computer. Here are my recent troubleshooting steps in order.
I was doing most of this through my phone. I have had no issues with any sites or flows except google. So I know my phone can read the implant correctly.
I decided to remove the implant from my google account again to try again and no dice.
I decided to remove the implant from my google account again and then try on my windows computer. This allowed me to add it as FIDO2 instead of U2F.
I Test by logging out and logging back in and it prompts for pin, and works as expected.
Going back to my android phone, logging out and then trying to use the new passkey. It doesn’t prompt for pin, then google says it is U2F even though it is working as FIDO2 on my windows 11.
So the interesting thing here is that the same implant with the same UUID can be used as both U2F and FIDO2. This is concerning on google’s end because it means you can still use hardware passkeys without google getting access to your resident keys on the device. They just silently fail saying that the device can only be used for MFA instead of failing and saying there was an error.
It might help to diagnose but I’m using Firefox for android on my Samsung S23 Ultra. I’ll keep digging and report back for future users that may run into this same scenario.
I believe on google i was able to actually register the same exact apex as both a “security key” for U2F and as a passkey.. and it worked in both contexts.
I believe you’re right. The odd thing is that I’m seeing some weird behavior from my implant. At least on webauthin.io it shows the implant with a blank ID
The first (NFC only) is my phone’s native NFC scanning, and the second (NFC and USB) is using the vivokey NFC bridge as the scanner. The bridge at least asks for the pin but still says unknown. Is this normal?
Edit: so users can find via search the screenshots are showing this information. The following being from windows 11 using an ACR122U instead of android but showing the different results:
Description:
device-bound passkey
It’s just the default request the RP (webauthn.io) is making.. it does not ask for attestation data by default. To get it, you must click Advanced Settings and select DIRECT;
Fun fact, if you change advanced settings to discourage user verification for new passkey registrations, it won’t ask for pin during passkey registration. That’s because the bridge will basically take the required and preferred setting for user verification and treat them the same - ask the user for a pin. However, it doesn’t matter what you said user verification for authentication to on webauthn.io, the Apex applet itself requires a pin for any resident key authentication. How things behave is a delicate dance between the relying parties request, the authentication tokens requirements, and the middleware in between with regard to how these different request settings are interpreted.
This is great information to have, thank you. Because the hardware never changes, and the webauthin site never changes only the middlemen as you will change I decided to run a full set of tests. I’ve noticed several things.
Summary: I’m unable to get FIDO2 reliably working on any browser even when using the bridge on my up-to-date samsung s23 ultra. I’m unsure of other users have run into these issues, but I’d really like to get my phone working with passkeys.
Here’s a chart with the results of each test.
| # | Settings | Pin Verification Requested | OS | Browser | Via | Result Description | Transports | AAGUID | Notes / Errors |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Default | Both | Windows 11 | Firefox | ACR122U | device-bound passkey | [“nfc”] | blank | — |
| 2 | Direct | Both | Windows 11 | Firefox | ACR122U | device-bound passkey | [“nfc”] | correct UID returned | — |
| 3 | Default | No | Android 15 | Chrome | OS | device-bound non-discoverable credential | [“nfc”] | blank | — |
| 4 | Direct | No | Android 15 | Chrome | OS | device-bound non-discoverable credential | [“nfc”] | blank | — |
| 5 | User Verification Required | N/A | Android 15 | Chrome | OS | — | — | — | OS doesn’t offer NFC option when UV is required on Chrome |
| 6 | Direct | On register | Android 15 | Chrome | Bridge | — | — | — | Flow through bridge ended “Success”; site error – “Unknown error talking to Credential Manager” |
| 7 | Default | On register | Android 15 | Chrome | Bridge | — | — | — | Flow through bridge ended “Success”; site error – “Unknown error talking to Credential Manager” |
| 8 | Default | No | Android 15 | Firefox | OS | device-bound non-discoverable credential | [“nfc”] | blank | — |
| 9 | Direct | No | Android 15 | Firefox | OS | device-bound non-discoverable credential | [“nfc”] | blank | — |
| 10 | User Verification Required | No | Android 15 | Firefox | OS | — | — | — | No PIN prompt even when UV required → “User verification required but not verified” |
| 11 | Default | On register only | Android 15 | Firefox | Bridge | device-bound credential of unknown discoverability | [“nfc”,“usb”] | blank | — |
| 12 | Direct + User Verification Required | On register only | Android 15 | Firefox | Bridge | device-bound credential of unknown discoverability | [“nfc”,“usb”] | blank | — |
that is interesting.
userVerification is a little bit of an interplay between relying party request, how the middleman transport interprets that request, and the requirements of the authenticator token. we made a decision about how to handle userVerification in Bridge; discouraged=no pin, preferred=pin, required=pin. on webauthn.io, user verification is preferred is the default option and I believe android google play services chooses to skip asking the user for it when registering. as I mentioned, some authenticator tokens may require UV for registration, in which case the token will reject it and android will prompt you for a pin and the registration on the authenticator token will be attempted again.
Our FIDO applet on Apex requires userVerification for any auth against a stored credential, so even if the RP says UV is discouraged on the request the token can demand it anyway (credProtect level 3).
It’s kind of a dance between all parts of the FIDO flow.
