Skip to content

Home

Jump to bottom Edit New page
Martin Paljak edited this page Feb 20, 2015 · 59 revisions

EID-WEB-TF

Task Force for smart card based eID usage on the Web with Desktop and Mobile devices.

Chair: Martin Paljak martin.paljak@ria.ee

Target: a polyfill for PKI smart card access in modern user agents (in addition to TSL Client Certificate Authentication) for daily operations which are not in scope for WebCryptoAPI: (signing, authentication etc). This means a modern, asynchronous (Promises) API with sufficiently generic yet applicable approach. Relates to WebCryptoAPI and WebCrypto.Next but is meant for use with existing credentials and existing browsers and due to the nature of centrally issued credentials, ignoring SOP (Same Origin Policy). Only use of pre-issued credentials, no provisioning like with <keygen>. The abstraction level exposed to application developer is WebCrytoAPI layer, not APDU layer.

Deliverable 1 - JavaScript API

Deliverable 2 - Reference implementation

  • hwcrypto.js providing the polyfill for a bunch of existing implementations:
    • Browser plugins with CurrentAPI
      • NPAPI (browser-token-signing)
      • IE BHO
      • Safari plugin
      • Google Native Messaging (chrome-token-signing)
    • localhost services
    • Other plugins
    • APDU interfaces

Deliverable 3 - Sample applications

  • debug.html with deeper technical status report of hwcrypto.js
  • sign.html which demonstrates the "give signature" operation with at least
    • Cards
      • Estonian eID
      • Finnish eID
        • probably also: Latvian, Lithuanian, Belgian, Spanish, Portuguese
    • Platforms
      • Windows (7, 8)
      • OSX (10.9, 10.10)
      • Linux (Ubuntu latest/LTS, Fedora latest)
      • Android (KitKat, Lollipop)
    • Browsers
      • Firefox
      • Chrome
      • IE
      • Safari
    • Technology bridges

On-host components

  • Some "native" code needs to be present on the host platform for talking to the hardware, be it a browser plugin or local web service or something else. The implementation details are left to component developers but generic implementation suggestions are given and the adapter framework described. The purpose of the API is to provide for "portable code".
  • Essentially all the relevant on-host components have a "NAT-traversal" nature, meaning that they enable to connect endpoints (web applications and pre-issued keys on a smart card) which browser vendors would not like to allow.
  • The de facto standard for extending browser capabilities has been NPAPI which is showing its age and is being actively abandoned by browser vendors (together with other relicts like Java applets).

Background reading:

Add a custom footer
Add a custom sidebar
Clone this wiki locally