Authentication fails on Android when using discoverable credentials created on external NFC authenticators that do not support ClientPIN.

[jy]

Steps to Reproduce
- Use an external NFC authenticator that does not support ClientPIN.
- Visit Webauthn.io on Android.
- Register a discoverable credential using the NFC authenticator.
- Attempt to authenticate with the newly created credential.
- Android displays: "Something went wrong"

Expected Behavior

Authentication should succeed, similar to behavior observed on iOS.
If ClientPIN is not supported on the authenticator, NFC interaction should be sufficient to establish User Presence (UP), allowing getAssertion or makeCredential to proceed for discoverable credentials.

[My1]

what authenticator are you using?

I am not aware of an authenticator with NFC but not clientpin

but when working specifically with discoverable credentials in their identity as discoverable either by storing them, or by sending a login without an allowlist, many webauthn clients I know force UV to be active on their end, so either the device comes up with internal UV or client PIN, if the device has no UV period, then that's fun.

however android's something went wrong might come from something entirely unrelated.

Android's CTAP2 over NFC specifically requires that the authenticator properly responds to the applet selection APDU with extended length, which unlike the actual FIDO commands being packaged for APDU is not needed to support extended length so quite a few devices fail on android over NFC even if they DO support client pin.

if you have a PC to play with, you can try sending the APDU

00 a4 04 00 00 00 08 a0 00 00 06 47 2f 00 01

and check what it does. if it craps out, then bio is not the issue here.

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/2dff1071-2089-4aa4-8ca5-46fd16c4e1ebn%40fidoalliance.org.

[jy]

yeah i think you're right. I'm building using Java Card and it rejects extended format when selecting applet. 

[jy]

https://issuetracker.google.com/issues/406833082#comment29

They’re saying they won’t support short APDU format for applet selection because the spec requires authenticators to handle both short and extended formats for FIDO2 commands.

However, I don’t think that requirement should be applied to applet selection itself. Applet selection is part of the card management layer, not the FIDO2 command set, and enforcing extended-only behavior there would break a number of existing Java Card applet implementations that already function correctly on iOS.

[My1]

yeah also it's not even just functioning on ios but also windows, and considering that we are talking about FIDO2 CERTIFIED devices I assume FIDO2 spec doesnt care about the applet selection, but that's something someone from FIDO Alliance needs to answer.

[Jackson Richardson]

Yes I need your approval support on my email 

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/f2114a41-4fc7-4303-a751-88a8e575d776n%40fidoalliance.org.

[Sayeed Anwar Syed Kamal]

Title: GMS sends extended-length applet SELECT over NFC; FIDO2-certified Java Card authenticators reject it (works on iOS/Windows/USB)

Confirming the applet-SELECT analysis from fido-dev thread VzOR9PnArZY with bench data.

Environment

• Moto G Stylus 5G (2024), Android 15, ST Micro NFC
• GMS com.google.android.gms 26.23.34 (262334035)
• Fails over NFC on Android: Hirsch uTrust FIDO2 GOV (NXP JCOP4, AAGUID 73402251-f2a8-4f03-873e-3cb6db604b03), Cryptnox, Token2, Feitian ePass
• Works on same phone/GMS: YubiKey 5 NFC (Infineon)

Symptom (Entra ID / any UV-required CTAP2 RP over NFC): SELECT returns U2F_V2, then 67 00 in ~18 ms, retries, doReconnect, exception at bxah.h:384 (bxaj), ~30 s hang.

Bench isolation — Identiv uTrust 3720 contactless reader, same card, varying only SELECT length-form:

Applet SELECT
Hirsch GOV (JCOP4.5)
YubiKey 5 NFC
Short 00 A4 04 00 08 A0000006472F0001 00
90 00 U2F_V2 ✓
90 00 ✓
Extended 00 A4 04 00 00 00 08 A0000006472F0001 00 00
67 00 (sometimes + ISO-DEP reset)
90 00 ✓

The JCOP4 applet accepts short-form SELECT and rejects extended-form SELECT — at the ISO 7816-4 card-management layer, before any NFCCTAP command. YubiKey accepts both.

Why this is a platform issue: these certified keys work over NFC on iOS and over PC/SC + USB-HID on Windows, all of which send short-form SELECT. Only Android/GMS sends extended-length SELECT, and only Android fails. Applet SELECT is ISO 7816-4 card management, not an NFCCTAP command — the binding's extended-length requirement is arguably scoped to FIDO command APDUs, not selection.

[Sayeed Anwar Syed Kamal]

Title: GMS sends extended-length applet SELECT over NFC; FIDO2-certified Java Card authenticators reject it (works on iOS/Windows/USB)

Confirming the applet-SELECT analysis from fido-dev thread VzOR9PnArZY with bench data.

Environment

• Moto G Stylus 5G (2024), Android 15, ST Micro NFC
• GMS com.google.android.gms 26.23.34 (262334035)
• Fails over NFC on Android: Hirsch uTrust FIDO2 GOV (NXP JCOP4, AAGUID 73402251-f2a8-4f03-873e-3cb6db604b03), Cryptnox, Token2, Feitian ePass
• Works on same phone/GMS: YubiKey 5 NFC (Infineon)

Symptom (Entra ID / any UV-required CTAP2 RP over NFC): SELECT returns U2F_V2, then 67 00 in ~18 ms, retries, doReconnect, exception at bxah.h:384 (bxaj), ~30 s hang.

Bench isolation — Identiv uTrust 3720 contactless reader, same card, varying only SELECT length-form:

Applet SELECT

Hirsch GOV (JCOP4)

YubiKey 5 NFC
Short 00 A4 04 00 08 A0000006472F0001 00
90 00 U2F_V2 ✓
90 00 ✓
Extended 00 A4 04 00 00 00 08 A0000006472F0001 00 00
67 00 (sometimes + ISO-DEP reset)
90 00 ✓

The JCOP4 applet accepts short-form SELECT and rejects extended-form SELECT — at the ISO 7816-4 card-management layer, before any NFCCTAP command. YubiKey accepts both.

Why this is a platform issue: these certified keys work over NFC on iOS and over PC/SC + USB-HID on Windows, all of which send short-form SELECT. Only Android/GMS sends extended-length SELECT, and only Android fails. Applet SELECT is ISO 7816-4 card management, not an NFCCTAP command — the binding's extended-length requirement is arguably scoped to FIDO command APDUs, not selection.

Request: send a short-form applet SELECT (as iOS/Windows do), or fall back to short-form when the authenticator rejects extended, instead of hard-failing with an unrecoverable reconnect.