Hardware Security (HaSec) Working Group Charter

DRAFT for discussion. Comments and pull requests welcome on github.

The mission of the Hardware Security Working Group, part of the Security Activity, is to define a set of Hardware-Based Web Security standard APIs providing Web Applications access to secure services enabled by hardware modules

Join the Hardware Security Working Group.

End date 31 December 2016
Confidentiality Proceedings are Public.
Initial Chairs
  • Virginie Galindo, Gemalto
  • David Rogers, Copper Horse
Initial Team Contacts
(FTE %: 20)
Rigo Wenning
Usual Meeting Schedule Teleconferences: Teleconferences to be held approximately weekly or biweekly as required. Task Forces may have separate calls that will not overlap with others.
Face-to-face: Up to 3 per year as required


The Hardware-Based Web Security Working Group will develop recommendation-track documents that define a standard to provide secure services for high security Web applications.

There are a number of use cases that this standard will enable, including but not limited to the ability to encrypt and to decrypt data using hardware based encryption modules, the ability to manage credential information for hardware based security modules, and the ability to access specific security sensitive services offered by hardware tokens. Such security sensitive services may include:

  1. Payments – transaction authorization
  2. Identity verification


This Working Group’s scope is Hardware-Based Web Security standard services, enabling Web pages the use of secure services enabled by security modules (TEE, secure elements, and other secure enablers with a demonstrated robustness to physical or software attacks). The group may produce non-Recommendation track documents within this scope. Recommendations are limited to the Restricted Scope Items described below.

Specifications like those to be produced by this group could impact user privacy and potential anonymity. Special care will be taken to avoid introducing fingerprinting and tracking threats in deliverables from this group. One mechanism to alleviate these potential problems is to place permission to use some functions under the user's control in a way in which the user understands the privacy implications. The group will seek review from the Privacy Interest Group.

Restricted Scope for Recommendation Track Deliverables

The Working Group Scope for Recommendation Track Deliverables will be restricted during this Charter period to the following Restricted Scope Items. Recommendation deliverables may only be added if they clearly fall within a Restricted Scope Item here. Restricted Scope Items must be carefully described so the types of technologies needed for implementation are clear. The group must recharter to add new Restricted Scope Items.

Web Services Interfaces

Services defined in this Working Group (under the Restricted Scope Items) could also be exposed, in Recommendation Track Deliverables, through Web Services to a nearby device or to the cloud. The APIs would additionally be described in terms of message content (e.g using JSON) that could be delivered by means like RESTful Web Services, Web Sockets, or some other message delivery mechanism. That would allow the same security services to be used outside the Web Browser context, in the Internet of Things for example, or as services from the cloud.

Out of Scope

The Working Group does not define how hardware security is accomplished. It defines how to ask hardware security for basic services where a secure hardware environment is available. The group will also not define crypto algorithms.

Success Criteria

The Group is successful if the following criteria are met:


Recommendation-Track Deliverables

Deliverables will be identified from among those listed in 2.1 and chosen by Working Group consensus. All Recommendations must have associated use cases describing the scenarios that the deliverable is intended to enable. These will be used to guide specification development. Use cases are not normative interoperability specifications. They are informative, so do not need to be in a REC track document.

The group may produce Recommendation-Track deliverables within the scope of the Restricted Scope Items of this Charter. These deliverables, when chosen by the Working Group, will be listed on the group’s homepage or the GitHub repo linked from the homepage, under the Restricted Scope Item in which they fit. When rechartering, specific Recommendation-Track deliverables could also be listed, but none are listed in this Charter.

Other Deliverables (not W3C Recommendations)

The group may also develop other deliverables that are not Recommendations. These are not limited by the Restricted Scope. As described above, these must be within the Working Group Scope. This could include use cases or best practices for using the APIs being developed or to explore possible future work in developing future versions of this Charter.

The Working Group will liaise with the Web Payments Working Group on web payments access. The expected non normative deliverables with Web Payments WG are use case and an architecture document, focusing on payment integration in the web payment API designed when payment means relies on hardware.

Dependencies and Liaisons

Internal liaisons

External liaisons

There are a number of external groups working in areas related to the ones in scope for the HaSec WG. The Working Group should determine whom to communicate with and then maintain communication with them. The following groups are likely to be important:


Participation is open to W3C Members and Invited Experts.

In order to make rapid progress, the group MAY form several Task Forces (TFs), each working on a separate topic. Group members are free to join any number of TFs.


This group primarily conducts its technical work on the public mailing list at public-hasec-wg@w3.org (archive). See W3C mailing list and archive usage guidelines. There is also a member-only list to be used for administrative or member-confidential purposes at member-hasec-wg@w3.org (archive).

Information about the group (documents under review, face-to-face meetings, etc.) is available from the Web Hardware Security Working Group home page.

Decision Policy

The group will aim to proceed by consensus.

Where there is consensus among the Working Group Participants, it will be forwarded as a consensus position. Where the group does not reach agreement, the different positions will be considered together.

All technical resolutions made by a meeting of the group are provisional until two weeks after being published to the mailing list. An objection made on the mailing list within two weeks of publishing a decision has the same standing as if it were made at the meeting.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

The Hardware Security Working Group also provides an opportunity to share perspectives on the topic addressed by this charter and create best practices documents. Those are not subject to the Patent Policy. W3C reminds Participants of their obligation to comply with patent disclosure obligations as set out in Section 6 of the W3C Patent Policy for those non-Recommendation-Track deliverables.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

About this Charter

This charter has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

WG Chair: Virginie Galindo (Gemalto)
HaSec Team Contact: Rigo Wenning

Last update: $Id: 2015-hasec-charter.html,v 1.11 2016/02/23 17:24:12 rigo Exp $