Skip to toolbar

Community & Business Groups

Web Crypto API Community Group

This group discusses Web Crypto APIs for signing the message by the user certificate issuing from the certificate authority for SSL communications. It is based on

Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

drafts / licensing info

Web Crypto API — An Authentification of Data and People in SSL

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

This group does not have a Chair and thus cannot publish new reports. Learn how to choose a Chair.

A draft charter of Web Cryptography

Here is a new draft charter of Web Cryptography instead of Web Identity.

The mission of the Web Cryptopgrahy Working Group is to provide Web developers secure and uniform access to elementary cryptographic operations for devices like browsers using common a Javascript API and safe key storage. This work will focus on increasing uniform support for asymmetric cryptography amongst browsers and in existing solutions although symmetric systems could be supported.

The Web Cryptography Working Group should aim to produce specifications that have wide deployment amongst end-users, and so should work carefully with as many major implementers as possible. The Web Cryptography Working Group should adopt, refine and when needed, extend, existing practices and community-driven draft specifications when possible. The cryptography work 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 will be developed for the specification to ensure interoperability, and the Working Group will assist in the production of interoperability reports.

I guess there are many missing things for key management and TLS based login/logout and HSM device based key handling etc.

A draft charter of Web Identity

The W3C has prepared Web Identity working group and make a draft charter. As following is main track for works.

  • Cryptography API
    Commonly-used cryptographic primitives should be made available to web application developers via a standardized API to facilitate common operations such as asymmetric encryption key pair generation, encryption, and generation, as well as symmetric encryption, hashing, and signature verification. This work can be based upon DOMCrypt, which has already been discussed in the W3C WebApps WG, HTML WG, and IETF Web Security WG.
  • Web Identity Sync
    This specification should specify how web application developers can synchronize of identity information across multiple devices like browsers. Synchronization should also work in the “Cloud” to support legacy browsers. Anonymous identities (i.e. an “empty” identity) and multiple identities should be supported. When possible, commonly used data-formats should be re-used and the design should take advantage of existing work such as Mozilla Sync.
  • Identity API
    This specification should specify how web application developers access session-state information and authentication credentials to enable functionality such as easier sign-on to services. This API will build upon existing work such as the Verified Email and Session Description Protocols (BrowserID), BrowserAuth, and may optionally propose possible changes to HTML to the HTML WG as well as specify transfer of identity-related data.
  • Each specification must contain a section detailing any known security implications for implementors, Web authors, and end users. The Web Identity WG will actively seek an open security review on all its specifications.

    To increase the convenience and security of deployment, these specifications may interact will take into account existing platform and operating system identity managers and so additional informative work in this area may be necessary.

It has processed mailing list for this work for general discussions. Please join us too.

Why Web Crypto API?

This is Channy Yun, an invited expert of W3C HTML W/G and a community leader of Mozilla in Korea. I have been interested in cryptography and certificate services in browsers because Korean law has restricted online financial transactions by national PKI infrastructure since 2000. The lack of browser features made wide third party plug-in as like ActiveX controls to issue and validate personal certificate, make digital signature for transaction messages.

Over 15 million certificates are issued and renewed in every year in Korea. As a result, Korean people couldn’t choose other browsers not to be supported plugin by bank, shopping and governmental sites. It’s not only Korea but also many countries with national certificate authority such as European and south American countries too.

I have tried to suggest and discuss this topic in WHATWG, HTML w/g and Webapps W/G during several years. Please read as following in HTML W/G.


As you knows, Korea’s browser monoculture has prevented tech innovations and user’s choice. It was caused by wrong implementation of digital signature by Korean govenment’s the law and national PKI system. Its technique has been based on browser plugin as like Active X and Java applet, so it also made many security problems on user’s PC. Nowadays 15 million personal certificates were issued and they are used in e-banking, trading and governmental sites to valid user and transaction in Korea.

Similarly some of European countries also had national PKI system including Denmark, Spain and etc. Denmark’s system was opensourced, but it is also based on browser plugins. It were dominated by VeriSign most of commercial market as like private CA service with issuing personal certificate and transaction with digital signature.

Many countries want to national CA and offer their service to citizen with assurance by law[4]. So I thought it needed browser-based web signing model by bad example of Korea.


I and some people suggested this issue to WHATWG because it was solved by browser vendors. Anders Rundgren also did own model of WASP – signing data in browser sessions and I did adding digital signature in >form< processing in HTML5.

As following is history of this issue.

Ian recommended us to continue this discussion in Webapps W/G. Andres
also has tried another efforts to solve issues in financial technical group.

Rebuilding of web signing

Maybe this long history was recognized by leading people of this group. I don’t convince whether the activity of web signing profile was made by this purpose or not. But, it seems to integrate with digital signature and there is no action further.

As you know, the technology situation was very changed in time raising this issue. Ajax was born and there are many web applications based on open standards and Web APIs.

So I want for you to consider this issue in this working group with new baseline and for to browser vendors to join this issue quickly before many countries commit a fault as like Korea. Brower’s functions as like crypto.signText or IE’s CAPICOM dll were deprecated in right now. So it is essential making new standard and implementation them.

Some of people have suggested to make my own spec draft and discussed this with people. So I finished Web Crypto API spec in June 2010. This specification was the result of many discussions in W3C HTML5 and Web Applications Workging Group and many people helped to make this including Anders Rundgren, Lucas Adamski, Kai Engert, Bob Relyea, Amax Guan, Gen Kanai, Minkyu Shin, Dongsan Lee and Jungsik Shin.

Web Identity Working Group

During my work, fortunetely, Mozilla has been deeply interested in this topic as like identity, security and cryptography. So David Dahl made a DOMCrypt spec and implementation in Mozilla. Finally it resulted Web Identity working group and will be soon.

This group will support web cryptography, certificate service and identity in browsers and gather many people outside W3C. Please join us!