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.