This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the smartcard industry and especially in the eID enabled countries, that is countries with a smartcard citizen identity card, working with smartcards in a website context is rather restricted. Currently the only decent way out of the browser's sandbox to talk to a smartcard is by loading a Java 6 applet which uses the javax.smartcardio API. We feel that this current approach restricts innovation in the smartcard+web application world: * applets are hard to style * applets require users to install Java 6 * in some environments Java 6 is not available, and in others it might be a threatened technology It would be a good thing if a web application could send APDU commands to smartcards using Javascript without requiring users to install browser plugins or Java 6. While for some smartcard applications having to install some software is no problem at all because they run in IT-operations controlled environments, citizen oriented applications are a completely different beast. Having no other requirements than to install a recent browser would be of great benefit to all users and application owners. Adoption of a smartcard API in the HTML5 spec is I believe the best guarantee to vendor adoption. A last note to avoid confusion: the smartcardio API is not only about keypairs and signing which could be handled by some keychain-like API. The smartcardio API is about talking any protocol to any smartcard embedded applet. I hope this request was submitted to the correct bug tracker. If not, sorry for wasting your time. thanks, Dieter Houthooft an identity and access management industry professional in a 100% eID roll-out country (Belgium)
How do you stick a smart card into your wifi-only tablet?
(In reply to comment #1) > How do you stick a smart card into your wifi-only tablet? You plug a smart card reader into your tablet. Android and iOS are perfectly capable of using add-on hardware. If I may assume that what you are saying is that most non-Java 6 environments don't have smartcard readers anyway: Java is sometimes not installed on desktops either. And besides that, having the choice between java applets and a Javascript API would release us from the stress "will Java still be generally available on desktop systems next year?". Mac OS X is getting more iOS like at every release and Android is moving from phones to tablets to notebooks.
(In reply to comment #2) > You plug a smart card reader into your tablet. Android and iOS are perfectly > capable of using add-on hardware. Users are just going to love purchasing and lugging around dongles that elegantly hang from their tablets. > If I may assume that what you are saying is that most non-Java 6 environments > don't have smartcard readers anyway: Java is sometimes not installed on > desktops either. My point is that hardware tokens are bad for the Web, because if they became widespread, they'd limit the possibilities of new classes of browsing devices to break into the market.
(In reply to comment #3) > (In reply to comment #2) > > You plug a smart card reader into your tablet. Android and iOS are perfectly > > capable of using add-on hardware. > > Users are just going to love purchasing and lugging around dongles that > elegantly hang from their tablets. > > > If I may assume that what you are saying is that most non-Java 6 environments > > don't have smartcard readers anyway: Java is sometimes not installed on > > desktops either. > > My point is that hardware tokens are bad for the Web, because if they became > widespread, they'd limit the possibilities of new classes of browsing devices > to break into the market. If hardware tokens became widespread supported, that would only enable users and improve security profoundly for those applications that choose to support it. Device vendors aren't going to feel threatened by a smartcard API. If anything, it will herald a new (old) class of devices that have a smartcard reader built-in. Those that choose not to include such a reader need only support USB. I don't see how any of this could lead to limitations on devices; on the contrary.
thanks for challenging :-) (In reply to comment #3) > Users are just going to love purchasing and lugging around dongles that > elegantly hang from their tablets. Of course they won't :-) But there are other use cases. It's not all about tablets. > My point is that hardware tokens are bad for the Web, because if they became > widespread, they'd limit the possibilities of new classes of browsing devices > to break into the market. tl;dr - the separate tokens are there and we have to use them :-( - the smartcard API also works for NFC connected chips or on embedded secure elements I agree with your ideal vision : separate hardware tokens should be avoided. But the road between now and an ideal world (if ever ...) is very long and is littered with web applications with crappy smart card integration. Service providers have to deliver apps that work with secure elements. Those service providers most often have no say in whether a smart card should be used or not. If Java's demise in the browser continues those service providers will be forced to abandon web applications and use native apps .. which would be a pity. Besides that, the same smartcard API is also used to interface to NFC connected chips and device-embedded secure elements. I should've added those in my initial description :-/
I don't understand what this has to do with the HTML spec. Wouldn't it belong in a crypto spec?
(In reply to comment #6) > I don't understand what this has to do with the HTML spec. Wouldn't it belong > in a crypto spec? It's not restricted to crypto, it works for any smartcard and nfc chip. Those are often used for crypto, true, but not exclusively. It could be used to read out and write to nfc tags, GSM SIM cards, payment cards, ... all from a web application without having to use java applets. In the java world, this API is located under javax.* instead of javax.security. Having said that, I am not sure where this feature request should be filed. Where are other Javascript API's like geolocation, web storage, etc ..."born"? What is the right way to get this feature up for discussion? Thanks in advance for any advice or help!
This bug was cloned to create bug 17815 as part of operation convergence.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Rationale: Hi Dieter, the features you describe do indeed have some value, but they are not being defined as part of the HTML spec. As you note, some APIs are birthed in other places. In this case, the W3C is currently in the process of chartering two groups that are related to what you describe: NFC WG http://www.w3.org/2012/05/nfc-wg-charter.html SysApps WG (notably: Secure Elements API) http://www.w3.org/2012/05/sysapps-wg-charter.html In both cases, while those groups do not formally exist yet the mailing lists that are listed in those draft charters are already up and running, and open to the public to join. I encourage you to!
Thanks for your response. The suggested workgroups indeed seem to be the right place.