Re: [webauthn] Add "smart-card" to AuthenticatorTransport enum (WebKit) (#1835)

Thanks for the tips!

> "nfc" is a shortcut for authenticators on an ISO 14443-3/7816-4 contactless interface - which NFC reader can communicate with.
>
> [...] But this is not a standardized transport... maybe in the next CTAP 2.2.

Both the CTAP and U2F specifications only specify command / response APDUs on an ISO 7816-4 level.  Even the CTAP 2.1 spec calls it ["ISO7816, ISO14443 **and** Near Field Communication"][0] (emphasis added), so you could squint at that and argue "ISO7816-3 contact cards are valid in the current spec".  After all, EMV also runs over both contact and contactless interfaces with not much distinction between them.

[0]: https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#nfc

However, I've only found a couple of vendors which claim to support that as a transport, and an [open source U2F JCOP applet](https://github.com/tsenger/CCU2F). Even composite authenticator devices which have a USB CCID interface (eg: Yubikey) don't support CTAP over that interface, even when they _also_ support NFC.

> We send a GetUID and if present, we treat the AuthenticatorTransport as nfc. It's only if we don't get a UID back we report "smart-card," which is meant to indicate a smart card with contacts. Again, contactless smart cards are treated as nfc.

That seems reasonable to me.

My request is that if this distinction is to be exposed over the WebAuthn API in some way, then it should be documented. 😄 

> ...there is no user presence gesture on smartcard in contactless. If you plug it through its contact interface, you should have more or less the same behavior than in contactless, the user presence is managed by the client.

This is similar to USB U2F devices which have no button (eg: PlugUp). You could also falsify the user presence check on both by power-cycling the interface (from software), and the PC/SC API offers a standard way for card readers mechanically ejecting or accepting cards.

I've also noticed the way that presence checks work on NFC devices differs by vendor (and even the ones that check could probably be falsified in the same way), but that's a whole _other_ can of worms.

> Microsoft is the only other platform supporting CCID readers as far as I know.

[webauthn-rs](https://github.com/kanidm/webauthn-rs) (which I wrote most of [its authenticator code](https://github.com/kanidm/webauthn-rs/tree/master/webauthn-authenticator-rs)) supports FIDO 2.0/2.1 authenticators via the PC/SC API, but calls it `nfc` for consistency with the WebAuthn spec, and it doesn't bother to do a `GetUID`.

If the `smart-card` transport identifier _was_ standardised, then I'd adopt it too. 😄 

> Windows has also been supporting contact smart card since day one. That's a result of how WinSCard is designed, and Microsoft decided not to go to the length of guessing if the card on the reader is read through contact or contactless interface.

It's more about how PC/SC is designed: on an application level, it's just a way to exchange APDUs with a card, and they're all a bunch of bytes... it doesn't really matter whether that's a contact or contactless interface. You could design an optical smartcard interface, and as long as you have IFD handlers for it, and it talked ISO 7816-4, that'd all just work for existing applications 😜 

The Windows WebAuthn API [only declares a constant for "NFC"][1], and its PC/SC code is all in the `MicrosoftCtapNfcProvider`. So my guess is that they either opted to not make the distinction because the CTAP spec doesn't.

[1]: https://github.com/microsoft/webauthn/blob/9fb38aa2775e286f504fc087efc62e5557bee881/webauthn.h#L250

-- 
GitHub Notification of comment by micolous
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1835#issuecomment-1382660217 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 14 January 2023 04:43:39 UTC