I installed the new version with the debug logs.
Here is the screenshot and logs from logging into passkeys.io via Firefox on Android via NFC Bridge using a Passkey that was successfully enrolled via Chrome + Bridge
debug_log_1763059711672.txt (13.6 KB)
Is this one of those cases where it did not ask for PIN but successfully logged in?
Correct (oops, should have added that in the post)
it looks like passkeys.io is making a request that allows auth without pin.
to be sure let’s try this.. turn off debug mode to clear the log file, turn it back on, then on Firefox exclusively, perform a complete registration at passkeys.io, then be sure to click “sign out”, then perform an authentication, then send the log.
after that, clear the log file again, re-enable debugging, then do the same on chrome and post the log. we’ll see if we can determine what’s going on and if there is a difference with browser.
| Action | Firefox | Chrome | Notes |
|---|---|---|---|
| Enrollment via NFC Bridge |  |
 |
Firefox: Bridge says success, but cred not enrolled |
| Log-In via NFC Bridge | * |
|
*Firefox: Not prompted for PIN; Chrome: Not prompted for PIN, not logged in |
I’ll post the enrollment/log in logs for each, clearing in between, using the same browser for both
yeah.. i def want to see all that in log form. in fact i’m improving log output for human readability but the current version should capture everything just fine. just call out what scenario each log file is for.
v1.3.10 pushed to Google for review with enhanced human readable debug logging
debug_log_chrome_enrollment.txt (25.5 KB)
debug_log_firefox_enrollment.txt (14.7 KB)
debug_log_windows_chrome_qr_blueooth.txt (26.7 KB)
No longer working (worked on both browsers last week) – might have something to do with me setting up Windows Hello between then. After entering PIN, the card immediately goes into a disconnect/reconnect cycle and the Windows dialog never goes away.
can you confirm exactly what FIDO applet and version you have loaded to the card?
From the log it looks like multiple tag connect events occurred, which indicates NFC connection with the tag was lost and recovered. This could boil down to a coupling problem, which is not uncommon when dealing with full size cards on some phones.
For whatever reason, passkeys.io requested a non-discoverable credential;
2025-11-13 12:43:24.300 [DEBUG] NfcActivity: Discoverable Credential: false
This is expected behavior, and authentication should succeed if you provide the same user name aaa@b6bb.com when attempting to authenticate.
this is likely a coupling problem as well.. at least it looks that way from the log.
I will update the UI to make it more clear about what’s happening with the token as the process proceeds. I may also call out the type of credential being registered as a basic UI element as well, not just debug data while debug is enabled.
that is just odd behavior and i might consider removing the fido applet from the card and re-deploying fresh with the latest version.
Apex Manager says v0.4.
I’m installing via the flex secure applets … I think the build is v0.18.6.
It looks like there is a slightly newer version of the open-source fido2 applet. I’ll try using that one later and see if it makes a difference.
I’m not creating or provisioning any personal attestation certificate. I don’t think that should matter for these tests, since enrollment/auth is working via Windows without attestation
I agree that’s how it looks, but I really don’t think it is a coupling issue. I’ve tried multiple orientations, case on, case off, repeater on, repeater off. It is taking the same amount of time to show the disconnection error no matter how the card is presented.
That part is really weird because passkeys.io isn’t asking for a username. I also ensured that I cleared local/session storage after enrollment, before logging in. I even tried logging in in a private tab, and I still get the auto-login without a PIN request. Somehow they are linking my card and/or discoverable credential to an account without a PIN requirement.
I did notice that if I have two different passkeys.io credentials on the same card, only the first is used when logging in.
The same non-PIN, non-asking for a username happens with a new incognito tab on Android Chrome.
Maybe this is a back end passkeys.io issue? But on Windows 10 + Firefox, I’m definitely prompted for the PIN then after entering it given a choice of which account to select
Thanks. Yesterday, I uninstalled/reinstalled the applet, then used VK NFC PM to set the PIN. That was how I ran the previous tests with the logs.
Just now I uninstalled/reinstalled the applet, attempted to enroll passkeys.io via Firefox + Windows, and Windows prompted me to create a PIN. I created the PIN and enrollment was successful.
So either the uninstall/reinstall or the setting of the PIN via Windows made a difference in direct enrollment on Windows.
This could be a samsung nfc stack issue, not you. They heavily modify their NFC stacks for “beam” and samsung pay. Try disabling any other NFC service and try it?
I think this might be a shortcoming of bridge - multiple resident keys for the same RP.. I think bridge will just pick the first one it finds. I will have to write a UI for presenting multiple options.. on the “to do” list now.
don’t know why but glad it’s working on Windows now hah
I’m running 1.3.10, pin caching off, grapheneos, firefox
Few weird things. When testing using webauthn I’m setting attestation to direct, but I never see that reflected in the debug logs.
Also, adding ?debug=true, I’m seeing this error
yeah for real debugging i tend toward See your WebAuthn config in action .. not sure why webauthn.io on your setup is not setting attestation request properly
Not well versed with the options, can the vivokey bridge app just override the attestation setting to always be direct?
attestationObject: {
"fmt": "none",
"attStmt": {},
"authData": {
"rpIdHash": "e9a88899f0e3ab9b98f693e0738a37725a3ef8130f3696b24ddddb145024880d",
"flags": {
"userPresent": true,
"reserved1": false,
"userVerified": true,
"backupEligibility": false,
"backupState": false,
"reserved2": false,
"attestedCredentialData": true,
"extensionDataIncluded": false
},
"signCount": 396,
"attestedCredentialData": {
"aaguid": "00000000-0000-0000-0000-000000000000",
"credentialId": "317c3c412ba129c8f784e47d418faad925c719b3491e75c12a52c56548bb3aa6390169f99f5e57dae3f130247481f88aee232f4e20a755c6d82fb85c0744c52c6846d52cbe7fbdc88555422c8603a95699f01e0a1182faa3d1bf591a9fcc2730221e19d4250da2e23af638f7e8638507",
"credentialPublicKey": {
"kty": "EC",
"alg": "ECDSA_w_SHA256",
"crv": "P-256",
"x": "CXxenmMVls2fpSBkOGYKQZE2bbo/a3tEr6eKZoog5WA=",
"y": "vgrJOACdjjtwbiqv5W3uFOT77QhbOYjUCGrUlZULHmY="
}
}
}
},
This was webauthn. me/debugger. Even when setting attestation to direct it showed as none in the bridge app
And this is on an Apex with recent Fido applet loaded? What version number does it show for the Fido app on Apex Manager?