[BUG] PIN state inconsistency and "No relying parties found" error after credential overwrite/retry

[GN998]

Browser: Edge 145.0.3800.70
Card: NXP JCOP4 P71
OS: Windows 11 25H2
NFC Reader: ACR122U-A9
Software: Authnkey

I originally had a Microsoft account bound, and previously bound a Discourse forum non-discoverable credential as 2FA.

But today I tried to bind a Discourse forum passkey for passwordless login. When using the passkey, I couldn't bind it; it prompted timeout/unsuccessful (using Microsoft QR code here, scanning the code with a phone and then using Authnkey to verify PIN and add).

Then I tried to re-bind on Windows desktop using the ACR122U reader, and found it prompted me to create a PIN. I stopped the binding here.

I did not reset the smart card. Then I used Authnkey on my phone to try and re-create the PIN, and found there was already an established Discourse discoverable credential, possibly created last time.

Previously it was not successfully bound to the Discourse account, so I re-bound it using the ACR122U. This time I found that the discoverable credential could not be seen, but the Discourse account was successfully bound.

However, when using Authnkey on the phone to view the credentials, a bug appeared on the card showing "No relying parties found", and no specific credentials were displayed.

Additional Context：

Note: I am using a translation tool, so there may be some language ambiguity. I can provide the Windows 11 Event Viewer error logs; please let me know if you need them, and I will prepare them for you.

This bug, where the Authnkey mobile app shows "No relying parties found," has occurred 3-5 times now. Yesterday, the card was on the table with my phone resting on top of it; it is possible that the issue is related to frequent movement or NFC connection instability. I hope this information is helpful to you.

[GN998]

Related WebAuthn logs

fido2.xml

Full Reproduction Steps:
It has been observed that after credentials are successfully added, if the account is removed via the web interface while the record remains on the smart card, re-adding the same user will directly trigger the bug. "No relying parties found"

The proposed fix is as follows:

FIDO2Applet/src/main/java/us/q3q/fido2/FIDO2Applet.java

Line 1057 in 80a1872

} else if (targetRKSlot < (short)(numResidentCredentials - 1)) {

                } else {
                    uniqueRP = residentKeys[targetRKSlot].isUniqueRP();                    
                    if (targetRKSlot < (short)(numResidentCredentials - 1)) {

[BryanJacobs]

Thanks for the report and log. The assessment there is correct; if an RP only has one credential, overwriting it breaks cred enumeration (but not reuse).

A fix has been released in version 2.1.0 of the applet.

[GN998]

Got it. Thanks for the explanation and the update! I'll move to v2.1.0

[GN998]

Sorry, I re-tested it and the BUG still triggers.

It is likely that when overwriting an existing credential, the program incorrectly inherits the display state ( flag) from the old credential at the end of the list.uniqueRP

I had the code analyzed by AI and updated the reproduction steps. Actual actions:

Open https://webauthn.io/, set User Verification to “Required” and Attachment to “Cross-platform”.

Register two accounts: “user-1” and then “user-2”.

Log in as “user-1”, then remove “user-1” from the website's interface.

Register “user-1” again.

Check the card using the “Authnkey” mobile app; it now throws the error "No relying parties found".

To provide some additional context:

The first time I encountered this bug, it involved single accounts across different websites (e.g., Site A, Site B, Site C). I had removed the account from the website's interface, but the credential remained stored on the smart card. For instance, if I had accounts 'a', 'b', and 'c' and removed 'c' from the site, re-registering 'c' would immediately trigger the bug.

In my second test (the current one), I used three different accounts on the same website: 'a1', 'a2', and 'a3'. When I removed account 'a1' from the website's UI but kept it on the smart card, and then re-registered 'a1', the bug was also triggered immediately.

I should mention that I am not a programmer and do not have a background in coding. Please let me know if there are any issues with this explanation or if you need further clarification.

[GN998]

I’ve uploaded a new error log to help you pinpoint the issue. Let me know if you need any others.

fido2_v1.0.xml

[BryanJacobs]

Thanks for the logs. There was, indeed, another test case necessary.

I've added a test and a fix.

[GN998]

Thanks for the logs. There was, indeed, another test case necessary.

I've added a test and a fix.

Thanks for the update. I tested it and it works now.