Web Cryptography Working Group Charter

The mission of the Web Cryptography Working Group, part of the Security Activity, is to define a high-level API providing common cryptographic functionality to Web Applications.

Join the Web Cryptography Working Group.

End date 31 January, 2017
Confidentiality Proceedings are Public
Co-chairs Virginie Galindo (Gemalto)
Team Contacts
Harry Halpin (FTE %: 15)
Wendy Seltzer (FTE %: 15)
Usual Meeting Schedule Teleconferences: topic-specific calls may be held, normally weekly.
Face-to-face: the Working Group will meet during the W3C's annual Technical Plenary week; other additional F2F meetings may be scheduled as needed.


The Web Cryptography Working Group will develop a Recommendation-track document that defines an API that lets developers implement secure application protocols on the level of Web applications, including message confidentiality and authentication services, by exposing trusted cryptographic primitives from the browser. This will promote higher security insofar as Web application developers will no longer have to create their own or use untrusted third-party libraries for cryptographic primitives.

There are a number of use cases that this API will enable, including but not limited to:


The Working Group will determine use cases that the API needs to support and use these to derive requirements. Success will be determined by the implementation of primary API features as defined in this section of the charter. Secondary API features shall be derived from requirements driven by concrete use-cases that will be detailed in the group's initial non-normative use cases and requirements document. Any secondary API features may be implemented in a Recommendation-track documents if the Working Group reaches consensus on both the use-case and the proposed API features. API features that are not implemented due to time constraints can be put in a non-normative "roadmap" document for future work.

Primary API Features in scope are: key generation, encryption, decryption, deletion, digital signature generation and verification, hash/message authentication codes, key transport/agreement, strong random number generation, key derivation functions, and key storage and control beyond the lifetime of a single session. In addition, the API should be asynchronous and must prevent or control access to secret key material and other sensitive cryptographic values and settings. Encryption and decryption include both symmetric and asymmetric cryptography.

Secondary API Features that may be in scope are: control of TLS session login/logout, derivation of keys from TLS sessions, a simplified data protection function, multiple key containers, key import/export, a common method for accessing and defining properties of keys, and the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption.

Out of scope: features including special handling directly for non-opaque key identification schemes, access-control mechanisms beyond the enforcement of the same-origin policy, and functions in the API that require smartcard or other device-specific behavior.

Note that the details of any user experience (such as prompts) will not be normatively specified, although they may be informatively specified for certain function calls.

The Web Cryptography Working Group should aim to produce specifications that have wide deployment. The Web Cryptography Working Group should adopt, refine and when needed, extend, existing practices and community-driven draft specifications when possible. The APIs should integrate well with Web Applications and so should be developed in concert with Web Application developers and the Web Application Security and HTML Working Groups. Comprehensive test suites should be developed for the specification to ensure interoperability.

Success Criteria

In order to advance to Proposed Recommendation, the specification is expected to specify at least all primary API features and expected to have two independent implementations of each API feature defined in the specification.


Recommendation-Track Deliverables

The working group will deliver at least the following:

The specification must contain a section detailing any known security implications for implementers, Web authors, and end users. The Web Cryptography WG will actively seek an open security review.

This specification should take advantage of existing platform and operating-system cryptography libraries.

Other Deliverables

The Working group will deliver at least the following non-normative documents:

Other non-normative documents may be delivered:


The production of the deliverables depends upon the resources available, and will change as new information and implementation experience is reported to the group. The most up-to-date timeline is available from the Web Cryptography WG page.

Note: The group will document significant changes from this initial schedule on the group home page.
Specification FPWD LC CR PR Rec
Web Cryptography API June 2012 October 2013 June 2014 September 2014 January 2015

Dependencies and Liaisons


HTML Working Group
To co-ordinate with any cryptography-specific or other security features that may need to be added to HTML.
Web Applications Working Group
To co-ordinate with APIs and features of Web Cryptography with other existing and planned Web application APIs.
WebAppSec Working Group
To co-ordinate with any security requirements and specifications arising from the security needs of Web applications.

Furthermore, the Web Cryptography Working Group expects to follow the following W3C Recommendations, Guidelines and Notes and, if necessary, to liaise with the communities behind the following documents:

External Groups

The following is a tentative list of external bodies the Working Group should collaborate with:

Internet Engineering Task Force
The IETF is responsible for defining robust and secure protocols for Internet functionality. A clear relationship with IETF is vital to ensure the security and success of elements of Web Cryptography that supervenes upon protocol-level work. Security reviews should involve participants from the IETF Security Area. In particular, the IETF JavaScript Object Signing and Encryption (JOSE) Working Group is producing formats relevant to the Web Cryptography Working Group, and therefore an official liaison is necessary in particular with the JOSE WG.
ECMA Technical Committee 39 (TC39)
This is the group responsible for ECMAScript standardization and related features. As the Web Cryptography Working Group may require additional features from ECMAScript, it should collaborate with TC39.


To be successful, the Web Cryptography Working Group is expected to have 10 or more active participants for its duration and to have the participation of industry leaders in fields relevant to the specifications it produces. The Chairs and specification Editors are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other Participants.

The Web Cryptography Working Group will also allocate the necessary resources for building test suites for each specification.

The Web Cryptography Working Group welcomes participation from non-Members. The group encourages questions and comments on its public mailing lists, as described in Communication. As needed, the group may also call for joint teleconferences and meetings with related organizations and standards bodies in the field of security.

The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy. The Working Group may also call for the formation of Community Groups or work in other standards bodies such as the IETF.


Most Web Cryptography Working Group Teleconferences will be conducted on an as-needed basis. Normally, at least one teleconference will be held per week.

Most of the technical work of the group will be done through discussions on one of the group's public mailing lists, for which there is no formal requirement for participation:

The group will use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a particular member requests such a discussion.

Information about the group (for example, details about deliverables, issues, actions, status, and participants) will be available from the Web Cryptography Working Group home page.

Decision Policy

As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an Editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.

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.

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

About this Charter

This charter for the Web Cryptography Working Group has been created according to section 6.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.

On 25 September 2013, this charter was edited to reflect the group's extension through March 2015. At the same opportunity, the milestones reflected in this charter were updated.

On 18 March, 2015, this charter was updated to reflect the group's extension through September 2015.

On 16 September, 2015, this charter was updated to reflect the group's extension through March 2016.

On 29 March. 2016, this charter was updated to reflect the group's extension through September 2016.

On 20 September, 2016, this charter was updated to reflect the group's extension through January 2017.

Harry Halpin, <hhalpin@w3.org>, Team Contact
Wendy Seltzer, <wseltzer@w3.org>, Team Contact
Virginie Galindo, Gemalto, Chair

$Date: 2016/09/26 12:17:52 $