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.

[Sergio Lopes]

Hi,
     
  Your findings are consistent and i used claude to help complemente with what's I known about Windows's WebAuthn platform architecture. Here's what I can offer
  on each question: 

 Question 1 — Is this a known limitation?
 
  Yes, this is a known (though not formally documented by Microsoft) platform behavior. The FIDO CTAP2.1 specification
  itself is completely transport-agnostic regarding getPinUvAuthTokenUsingUvWithPermissions (subCommand 0x06). The only
  prerequisite the spec defines is:

   "This subCommand is only applicable when the authenticator supports built-in user verification methods. This
  subCommand MUST be implemented if the authenticator returns both uv and pinUvAuthToken option IDs set to true in the
  authenticatorGetInfo response."
   — CTAP2.1-PS, Section 6.5.5.7.3 [1]

  There is no normative or informative text anywhere in the spec restricting this subcommand to any specific transport.
  The spec's architecture statement is explicit:
 "A FIDO2 Authenticator can be accessed by a CTAP client through a variety of transport mechanisms. This
  specification only concerns itself with the logical CTAP messages themselves, not with the physical transport layer."

  So the restriction you're observing is a Windows platform implementation decision, not a spec-level prohibition.

Re: Question 2 — Intentional or bug?

  Most likely an architectural design decision, not a regression. On Windows, the device stack for FIDO2 authenticators
  is bifurcated:
USB HID devices with FIDO usage page are enumerated as FIDO authenticators and receive the full WebAuthn treatment
  (including biometric UV flows). CCID devices enter the PC/SC subsystem, which historically serves certificate-based
  smart card authentication. The fact that you're seeing CTAP2 commands at all over CCID likely means Windows is using a
  credential provider path that supports PIN-based FIDO2 over smart card (for Entra ID / CBA scenarios), but the UV
  interaction flow was never implemented for this path.

  The UX reasoning likely is: CTAPHID authenticators with built-in biometrics (YubiKey Bio, FEITIAN BioPass) present as
  self-contained security keys where the user interacts directly with the device. The Windows UX for "touch your
  security key" / "scan your fingerprint on the key" is designed around that HID-enumerated model. CCID-connected
  devices, from the platform's perspective, are smart cards in a reader — a form factor where on-device biometric
  interaction isn't the expected UX paradigm.

Re: Question 3 — Any workaround?
 
  Based on publicly available information, your options are:

  1. Re-expose over USB HID (CTAPHID): As you noted, this is the reliable path. If your hardware supports composite USB
  (HID + CCID), exposing a CTAPHID interface with FIDO usage page (0xF1D0) alongside CCID should make Windows enumerate
  it as a full FIDO2 authenticator with UV support.
  2. Dual-interface approach: Some implementations (e.g., Feitian's JavaCard-based authenticators) expose both a CCID
  interface (for certificate/PIV operations) and a HID interface (for FIDO2). The HID interface gets full WebAuthn
  platform support.
  3. Wait for platform changes: There's no published roadmap from Microsoft indicating CCID UV support is planned, but
  Windows Insider builds occasionally expand FIDO2 support.

  Other platforms (macOS, Linux via libfido2, ChromeOS) do support full CTAP2.1 UV over CCID — Yubico's libfido2 [2]
  implements UV identically across all transports (see src/fido2/dev.c transport dispatch). This confirms your
  implementation is spec-compliant; the gap is Windows-specific.

Re: Question 4 — Transport factoring into PIN vs. UV decision

 

  Your packet captures confirm this conclusively: Windows queries getUVRetries (0x07) — proving it reads the

  authenticator's UV capability — then ignores it and proceeds with getPinUvAuthTokenUsingPinWithPermissions (0x09). The

  decision to skip UV appears to be made after capability discovery, based on transport classification.

 

  Microsoft's FIDO2 security key provider documentation [3] lists supported transports as "USB" (meaning HID), NFC (via

  the built-in NFC stack, not PC/SC), and BLE. CCID/PC/SC is conspicuously absent from the supported transport list for

  full FIDO2 operations.

  ---

  Sources:

 

  [1] FIDO CTAP2.1 Proposed Standard (2021-06-15), Section 6.5.5.7.3:

  https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html

 

  [2] Yubico libfido2 — CCID transport implementation (full UV parity with HID):

  https://github.com/Yubico/libfido2

 

  [3] Microsoft — FIDO2 security key provider requirements:

  https://learn.microsoft.com/en-us/entra/identity/authentication/concept-fido2-hardware-vendor

 

  [4] FIDO Registry of Predefined Values, Section 3.1 (User Verification Methods / uvModality values):

  https://fidoalliance.org/specs/common-specs/fido-registry-v2.2-ps-20220523.html

 

  ---

  The spec doesn't restrict UV by transport. Windows's webauthn.dll (and its credential provider chain)

  architecturally treats CCID-connected authenticators as smart cards with limited CTAP2 support (PIN only). The most

  reliable fix is exposing a CTAPHID (USB HID, usage page 0xF1D0) interface. All non-Windows platforms handle this

  correctly.

--

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/87b36c30-e222-4a8f-b196-8fe470e25facn%40fidoalliance.org.

[My1]

dumb question: can an NFC and/or chip smartcard even expose HID to begin with without cooperation of the reader? (which would make them kinda useless as you couldnt rely on existing readers anymore and might as well use a USB-based FIDO2-stick)

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAPpRXtLh6_YCVvJ1zLyZWU%2B0D5vkqnfiG%3DT372WBbf4S%3Dwd2ag%40mail.gmail.com.

[John Bradley]

No, it would need to be some Fido specific ccid reader.   Sort of defeats the point.  

We added contact smart card over ccid in CTAP 2.3.  Windows 11 has not added full support.   

The problem is the smart card stack they are using is not waiting for interaction.    The only thing that will work is a pin based smart-card that has no internal UP or UV that returns a response with UP set to true based on the insertion timer like NFC.  

I don’t know when or if win11 will address this for the small number of authenticators impacted.  

I did ask about Microsoft about it several months ago.    They considered it a hypothetical problem as no one has brought them any devices with built in UV that work over NFC or contact sled. 

I made a key with no HID transport to see how Windows would deal with it.   That is how I discovered that windows was not waiting for interaction as it would over HID and only working with authenticators that returned an immediate response to getAssertion or make credential.  

Regards

John B. 

Sent from my iPhone

On Aug 5, 2026, at 17:45, My1 <teamhyd...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNqsEJqpBwkA4StZ4snobBKQapPSM0obx7a%3D6C%3DM9fk0Rw%40mail.gmail.com.