Hardware Based Secure Services Report

Draft version - 29 April 2016

Latest version
Sebastien Bahloul / Morpho



Status of This Document

This specification was published by the Hardware Based Secure Services. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

Working copy

Table of Contents

1. Introduction

1.1 Terminology

2. Problem Statement

At this time Secure Element are not anymore usable by web applications. For years, various form factors have been usable thanks to many API and technologies (PKCS#11, Microsoft API like CSP / Minidriver, Java applet ...). Use cases are still here but not the browser access, especially on the mobile devices. This document is targeting to define the next generation Javascript API for hardware based keys management and usage, including the corresponding underlying components requirements to re-enable a strong security and identity ecosystem.

Single Origin Policy: one main matter of interest of this report is how to protect key usage outside the issuing origin:

Let's consider that a domain foo.com issue a key. Because the keys won't be accessible with a Javascript API from any domain, how the domain bar.com is allowed to use this key ? There is strong need for an access control model because the hypothesis of a trusted environment that every Secure Element relies on is not anymore valid with an API on the browser.

This first version of the report will not address this important issue but will focus on:

Further extension will be added to authorize various origins to use and manage a particular key.

Position to FIDO and WebAuth standards: this document is focusing on providing web developers means to issue and use identity keys (whether they are X509 certificates or any other cryptographic model with underlying asymmetric cryptography). FIDO standards is related to device authentication: in the FIDO vision, it is up to the relying party to manage the link between the credential and the identity.

Position to WebCryptoAPI standards: this report includes to WebCryptoAPI so that web developers can rely upon the same API but with a different initialization (like Java Cryptographic Engine with hardware provider).

2.1 Keys access

2.2 Keys management

2.3 User verification method

The user verification method is out of scope of this specification. But it should be clear whether a key is protected by

The Relying Party should take care that:

3. Use cases

QUESTION: Need to provide here names of well-known customers to help pushing the standards to browser makers?

3.1 Governments with eID for digital public services