proposals
proposals copied to clipboard
WICG
Smart Card API
Introduction
The objective of this API is to enable smart card (PC/SC) applications to move to the Web platform. It gives them access to the PC/SC implementation (and card reader drivers) available in the host OS.
While there are other APIs that provide the right level of abstraction and security properties for identity on the Web, such as WebAuthn, there are domain-specific functions which can't be captured by such higher-level APIs.
A remote access (aka "remote desktop") web app letting the remote machine access the host's card reader as if it were directly connected to it. Enabling PC/SC applications on that remote machine to work without modification, unaware that the card reader is not local.
A web-based kiosk could read even simple RFID badges via PC/SC and then display relevant information on a display. It's also not uncommon for such readers to need control commands to put them into the proper state for reading the particular type of card the application supports.
Feedback
I welcome feedback in this thread, but encourage you to file bugs against the Explainer.
Hi, I'm the founder the FreeRDP project, and had the unfortunate experience of dealing with RDP smartcard redirection by trying as best as possible to wrap WinSCard APIs over pscs-lite on different platforms to try and make it behave the same way. I see one of the stated goals is remote desktop, would it be fair to assume that this new Web smartcard API should be usable to build web-based RDP smartcard redirection? If so, I offer myself as tribute to provide feedback and ensure it has a chance of working in practice.
While the explainer states that solving all inconsistencies between the different native PC/SC stacks is a non-goal, I can tell you already it's a dead-end unless you actually try and solve most of the inconsistencies. There's a reason why even the official Microsoft RDP client on macOS still doesn't have full smartcard redirection today, something which took quite a fair amount of effort in FreeRDP. The last time I worked on it, the outdated pcsc-lite library on macOS didn't even support smartcard transaction calls, so we had to emulate this. To make matters worse, smartcard transactions aren't exactly "locks", but soft locks that can timeout after a certain time. Changes in locking behavior are sufficient to break things.
As for pcsc-lite, it's heavily inspired by the WinSCard APIs, but there are slight differences, especially for flags (one of them uses bit flags, and the other one is an enum, I forgot which is which). That's something translatable between the two, but one has to be careful. If your primary intent with this proposal is to enable smartcard redirection in remote desktop, I strongly suggest that the expected behavior is defined to closely emulate WinSCard on Windows as much as possible.
I am the maintainer of pcsc-lite. I agree with @awakecoding that it may be difficult to have the exact same API for the 3 versions on WinSCard on Windows, GNU/Linux and macOS.
I try to list the differences between pcsc-lite used on GNU/Linux and the Windows implementation at https://pcsclite.apdu.fr/api/group__API.html#differences
Of course Apple has its own version with some other differences like the lack of support for SCARD_AUTOALLOCATE or "\\?PnP?\Notification" for SCardGetStatusChange().
Hi @awakecoding and @LudovicRousseau,
The Web Smart Card API is intended to enable the use case of smart card forwarding in a remote access web app. And giving a web app access to the native PC/SC stack is enough for that.
I recognize that mimicking all the quirks of the MS Windows winscard in other platforms is a can of worms, but multiplatform remote access applications already tackle that (kudos to FreeRDP for doing so). Thus when a vendor or author decides to port his remote access app to being a web app, he will also port his solution for dealing with this problem (and the design decisions that come along with it) on top of the Web Smart Card API.
As you know better than me, there are irreconcilable differences: transaction timeouts, direct connection semantics, card reader name, reported status, error codes returned on particular situations, etc. I think the only way to have truly consistent PC/SC API behavior across platforms would be if the browser did not use the native PC/SC stack at all but instead implemented its own (like carrying around its own copy of PCSClite). Or settle on a higher level API, reducing the possible use cases when compared to bare PC/SC. But the chosen path in this API proposal was to, instead, acknowledge those differences and let the API user decide how he wants to deal with them.
As for the lack of support for "\\?PnP?\Notification" on MacOS, this is exactly the reason why this Web API has a promise-returning SmartCardResourceManager.watchForReaders(): it will yield a "NotSupportedError" in this platform. Having the browser implementing this feature by itself on MacOS would mean doing polling, which is not something I would like a browser to be doing behind the scenes. Better let the application consciously and explicitly do it if it really wants to. Then it can also decide on the polling interval and other impl details. Or, alternatively, show a different UI when watchForReaders() is not supported.
@dandrader This seems to have plenty of support for incubation. Do you want to move the explainer repo to the WICG org?
Hey, this made me think of Serial port use cases... wondered if you've taken a look at https://github.com/WICG/serial? (May not meet your specific use cases, but wanted to be sure you'd seen it.)
@cwilso Yes, how do I move the explainer repo to WICG org?
@travisleithead I did have a look at the Web Serial API (and Web USB, Web HID).
I’m guessing this moved to here: https://github.com/WICG/web-smart-card
Is that correct?
Correct, https://github.com/WICG/web-smart-card is the new home for this proposal.
@yoavweiss, sorry, what's the process for when a repo has been created for an incubation? do we (Chairs) close these?
I typically mark incubations as "repo_adopted", but leave them open. At the same time, I don't think we have a strict process nor am I sure we've been consistent with it. Might be worthwhile to think through how we want to keep track of adopted incubations throughout their lifecycle.
Hi dandrader.
I recently found some questions here that have not been answered. Please, see this: https://discourse.wicg.io/t/proposal-smart-card-api/5972
"I have some ideas to solve some of the smart cards problems you listed… or I have this questions:" "What do you think about the context of smart cards within the blockchain?" "Would this be possible a smart card in blockchain as a wallet in your proposal? (yes or no)" "Would this be possible a smart card be temporary? (yes or no)" "Is it possible for the browser itself to store and manage these smart cards? (yes or no)" "Is it possible to use the SQRL protocol with smart cards? (yes or no)" "Is it possible to store smart cards inside Solid? (yes or no)"
If you have time, could you clarify these doubts?
@yoavweiss I see this has been marked as completed, can you clarify what the outcome is? I haven't been following up on the original proposal much, does this mean an agreement has been reached and a web smartcard API should eventually make it to popular browsers that want to implement it?
The chairs decided to bulk-close all proposals that were adopted, as activity on them happens elsewhere. This incubation lives on in https://github.com/WICG/web-smart-card