- From: Thomas Duboucher via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 Jan 2023 14:06:33 +0000
- To: public-webauthn@w3.org
> Going off the [publicly published security requirements](https://fidoalliance.org/specs/fido-security-requirements/fido-authenticator-security-requirements-v1.5-fd-20211102.html) there is no reference to CCID at all. Still also looking for it. I'm sure we wrote it somewhere, but I can't find where... > 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"](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#nfc) (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. Yes, that was my clumsy attempt to clarify the spec... Basically, FIDO define what is a FIDO authenticator "that can be used with a NFC reader", and in the spec we define it at ISO 7816-4 level (and if you connect the dot, it should implement an ISO 14443 interface). > 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. Any dual interface smartcard with a FIDO applet should do the same, if the vendor didn't add specific code to prevent selection outside of contactless. > 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. Yes, you can falsify it from the p.o.v. of the token, who can't see the difference between a cold reset and a power cycle. But the actual check of user presence is done by the client software. > 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 😜 If you start playing with contact interfaces, you'll soon discover T=0, and you wish you hadn't. 🙃 > [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 > The Windows WebAuthn API [only declares a constant for "NFC"](https://github.com/microsoft/webauthn/blob/9fb38aa2775e286f504fc087efc62e5557bee881/webauthn.h#L250), and its PC/SC code is all in the MicrosoftCtapNfcProvider. So my guess is that they opted to not make the distinction to keep things simple, and because the CTAP spec doesn't. You made the same design decision as Microsoft. [libfido2](https://developers.yubico.com/libfido2/) did the same, they also have a PC/SC interface. -- GitHub Notification of comment by serianox Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1835#issuecomment-1384113985 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 16 January 2023 14:06:35 UTC