DRAFT
Hardware Security (HaSec) Working Group Charter

Scope

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.

• Secure Hardware Discovery & Attestation: Means of requesting access to a service that satisfies some criteria, with user approval. Means of indicating to the requesting Web page what party vouches that the service satisfies the criteria (e.g. digitally signed challenge; indication if Secure Hardware Component is isolated from Operating System, or just from Web Browser/UA). The other restricted scope items could be satisfied through references to some existing spec along with a way to request and verify the level of security of the implementation. For example, a secure worker restricted scope item (see below) could be satisfied by something like 1) reference to the Web Worker spec; 2) a means of requesting that a Worker be executed in an environment that cannot be tampered with even by the operating system and the response is signed by a trusted party verifying the implementation is available (with a nonce to prevent replay) and a token to use to request starting a worker in that environment; 3) extension to Web Workers creation to include passing the token; 4) API for the running Worker to ask environment to sign a challenge for attestation of the environment it is running in.
• Secure Hardware Crypto Key Discovery: Discovery of pre-provisioned, named, origin specific cryptographic keys for use with the Web Crypto API or an API provided by this WG.
• Secure Hardware Crypto Key Management: Importing, creating, deleting keys for a particular origin. Working Group would define trust/permission model for use of cryptographic functions.
• Secure Hardware Crypto API: Maintenance or extension of the Web Crypto API after the first version. May also define other Crypto API specifically for Secure Hardware.
• Secure Hardware Storage API: Origin specific storage and retrieval of data. This would prevent access by other applications on the device or even from the operating system depending on the level of security provided. This API could be restricted to be used only by a Secure Worker. This API must use or enhance (an) existing Web Platform storage API(s), not create a new storage mechanism. Additional APIs defined by the group could provide a way for the Secure Worker to determine whether stored data was already encrypted by the implementation so that the Secure Worker could decide whether to encrypt stored data itself. The Working Group could decide to make that API also available for querying in Web pages about normal storage implementations outside Secure Workers (to determine if they are encrypted sufficiently).
• Secure Hardware IO: Means to ask for and obtain user input that is protected against compromised operating system or UA/Browser depending on the level provided. This could return a digitally signed (by the hardware component) response from the user. This API is intended to be used only by a Secure Worker, as an optional API, and could be a very small subset of HTML for form input.
• Secure Worker: API to execute JavaScript or WebAssembly code in a Secure Hardware Component (allowing, but not necessarily requiring both scripting languages). Like a Web Worker this would communicate to the calling Web page code using a message channel provided by the User Agent/Browser. A Secure Worker would not necessarily have the same APIs available as a Web Worker and the spec would define the type of data that may be passed. APIs used by Secure Workers would be included by reference to specifications created under other Restricted Scope Items or other external sources. This Restricted Scope Item covers what is needed to create, execute and communicate with Secure Workers. Sharing Secure Workers could be restricted to be used from the context that created them, or could also be used from other contexts (tabs, iframes) from the same origin, or to other origins it specifies that it permits (like CORS).
• Binding mechanism: Means to bind the result of a secure communication to a secure hardware to a certain context, origin or transaction and restrict the validity of bearer tokens and other secure vouchers accordingly.
• Identity semantics: Means to extract identity information from a secure hardware under control of the user, including the choice or creation of the subsequent data format made available via the API.

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:

• Participation via mailing list subscription and postings from people representing various stakeholder communities, including banks, payment industry, various legal and regulatory bodies with mandates that are related to authentication, authorization and secure transmission, hardware and software developers, mobile operator companies, browser vendors and developers of secure applications
• Discussion of requirements and use cases and publishing a Working Group NOTE on use cases and requirements for hardware based security on the Web. The NOTE will determine the priority of the restricted items in section 2.1 to be addressed
• Successfully engage and coordinate with Groups working on Web Applications and their components as well as with other Security Groups within W3C and beyond
• Engage a dialog with the governmental identity systems that require a higher level of security