Moving away from PCSC

[serianox]

First of all, thanks for all the work done so far. :)

I'm a smartcard developer working at Thales, and I have among other had the opportunity to work on W3C/GP WebSE, including writing an implementation of it for Windows and Android based on PCSC and Android NFC API. I would be very interested to share my own experience.

As a legacy API, PCSC has a lot of quirks, among others :

• if a card is configured in T=0, the API does not send APDU but TPDU instead and the application developer has to deal with ISO 7816-3; if done improperly, the communication is stuck,
• if a card is configured in T=1, the API returns an ATR; only T=0 cards have an ATR, so PCSC generates a fake ATR in order not to break applications built when T=1 didn't exist,
• T=1 cards do have an optional ATR stored in EF.ATR, in which case the ATR returned by PCSC is not valid,
• did I mention that cards can have both T=1 and T=0 and the selection between both is not guaranteed?
• what about ISO 14443-4 cards (contactless)? well, PCSC mock a T=1 card, which mocks a T=0 card, etc

In addition to all those issues, PCSC is only available in "desktop" for devices that looks like smartcards. However, today smartcard come on many devices, e.g. smartphones, with newer APIs

• Android and iOS own NFC API
• Open Mobile API and many new form factors/protocols
• contactless cards (14443-3)
• UICC (T=0), eUICC
• eSE (HCI, I3C)

The common denominator to all of those are they all communicate using ISO 7816-4 APDU.

As such, my advice would be to loosen the hard connection to PCSC, and build the API only to focus on 7816-4.

[dandrader]

Hi Thomas,

Thanks for taking the time to contribute with your expertise on the topic. I really appreciate it.

Those are good points and I agree PCSC has lots of quirks. By having the Web API being very close to PCSC, it would be up to the API user to deal with those quirks, just like it would do when using PCSC directly. The Web API also doesn't solve the inconsistencies between PCSC implementations (ie, winscard, MacOS fork of PCSClite and PCSClite proper) and again it's up to the Web API user to decide how to deal with them. Thus this API enables PCSC usage in web apps but doesn't solve its inherent problems. See related discussion in the WICG proposal.

As stated in the explainer, it's a non-goal to provide a higher-level API. This is because some of the motivating use cases need explicitly PCSC. Namely Remote Access Applications and Badge reading kiosks. Would they still be possible with the approach you propose?

[serianox]

Hi Daniel,

Thanks for this very precise answer. I apologize for not answering earlier, it seemed probably impolite.

Your approach is much more realistic than building a new API. Though I'm still convinced that in the future we will need an API that's safer to use and more homogenous between platforms.

I am confident that the use case you are proposing can be achieved with a higher-level API, such as WebSE. However, nothing prevents us from building a higher level API from this low-level API - while the other way around is probably impossible, including low-level access to reader functionalities such as pin pad.

I can't overstate how impatient I am to see this API going live. It will be a real improvement over how applications accessing smart card are written today.

(to be entirely honest, one of my toy project in never finished/published was a WebSE implementation for Node based on the existing pcsclite bindings - I would probably restart it once the first test code )

[dandrader]

Hi Thomas,

[...] nothing prevents us from building a higher level API from this low-level API [...]

Exactly. The Web Smart Card API will be an enabler for JS libraries providing such APIs.