Windows never sends ClientPIN subCommand 0x06 (getPinUvAuthTokenUsingUv) for a CCID-transport CTAP2.1 authenticator — expected behavior or platform limitation?

[조병구]

Hi all,

We're developing a JavaCard-based FIDO2/CTAP2.1 authenticator with an

on-card fingerprint sensor (match-on-card, uvBioEnroll supported). The

device is connected to the host via a USB CCID smart card reader

(PC/SC), and the FIDO2 applet is selected via the standard NFC/CCID

transport binding (AID A0 00 00 06 47 2F 00 01, CLA=0x80 INS=0x10

NFCCTAP_MSG).

Problem:

On Windows (both the native "Security key" sign-in screen and browser-

based WebAuthn/Entra CBA sign-in), the platform authenticates using

PIN only. Fingerprint verification is never attempted, even though the

device fully advertises biometric support.

authenticatorGetInfo (relevant fields):

"options": {

"up": true, "uv": true, "uvAcfg": true, "bioEnroll": true,

"uvBioEnroll": true, "clientPin": true, "pinUvAuthToken": true,

"alwaysUv": false

},

"uvModality": 2

We captured USB traffic (Wireshark + USBPcap) across multiple sign-in

sessions (30-70+ seconds, several retries each). Findings, consistent

across every capture:

- authenticatorClientPIN subCommand 0x07 (getUVRetries) IS sent,

and the response reports a healthy uvRetries value (5, not

blocked).

- authenticatorClientPIN subCommand 0x09

(getPinUvAuthTokenUsingPinWithPermissions) is used for every

actual sign-in, and succeeds.

- authenticatorClientPIN subCommand 0x06

(getPinUvAuthTokenUsingUvWithPermissions) is NEVER sent — 0

occurrences across every capture, even though the platform

clearly queries UV retry state via 0x07 first.

So Windows appears to check UV availability, but never actually

attempts to obtain a UV-based token from this authenticator — it

falls straight to PIN every time.

For comparison, native USB-HID CTAPHID biometric security keys (e.g.

YubiKey Bio - FIDO Edition, FEITIAN BioPass FIDO2/Bio) are documented

to support fingerprint-only sign-in on the same Windows sign-in

screen. The only architectural difference we can identify is the

transport: CTAPHID over native USB HID vs. CTAP2 over CCID/PC-SC.

Questions for the list:

1. Is it a known/documented limitation that Windows's WebAuthn

platform (webauthn.dll) does not attempt

getPinUvAuthTokenUsingUvWithPermissions for CCID-transport

authenticators, regardless of advertised capabilities?

2. If so, is this intentional (e.g. UX/security design decision tied

to transport) or a platform gap/bug similar to the CTAP handling

regressions discussed elsewhere on this list?

3. Is there any supported way to get Windows to attempt UV (rather

than PIN) for a CCID/PC-SC-connected CTAP2.1 authenticator, short

of re-exposing the authenticator over native USB HID (CTAPHID)?

4. Has anyone from Microsoft, or anyone with visibility into

webauthn.dll's authenticator-selection logic, could confirm

whether transport type factors into the PIN vs. UV decision?

Happy to share full pcap excerpts or additional getInfo dumps if

useful. Windows build: [여기에 실제 Windows 빌드 번호 winver 결과 기입].

Thanks in advance for any insight.

Best regards

[조병구]

Best regards,

[John Bradley]

CCID smart card was only added in CTAP2.3.  

That said as far as I can tell there is still a bug regarding waiting for interaction over the contact interface.  

I did test it working with a contact smart card that is not have internal UP.  

You will need to take it up with Microsoft.   Make sure your Authenticator passes the Fido CTAP 2.3 conformance tests for smart card.  

Regards. 

Sent from my iPhone

On Aug 5, 2026, at 06:25, 조병구 <jbk...@gmail.com> wrote:



--
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/3c87c445-ef4f-4919-a186-fe25781bbabdn%40fidoalliance.org.

[My1]

Isn't ccid the base protocol used for nfc cards already anyway? With nfc being part of fido2 kinda since the beginning? 

Heck i have successfully used fido2 over contact chip cards in 2020 already. 

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/E7E52AF5-BCF9-46A8-B6F4-6B7CF7B2918F%40ve7jtb.com.