Web Cryptography

In v1.15, the Web Crypto API still makes heavy use of special interface-objects in order to provide asynchronous implementations of methods such as encrypting, hashing, or generating keys.

However, in nearly every major cryptography API, these operations are all synchronous, and thus user agents will be forced to simulate an asynchronous API atop a synchronous API.

Does it make more sense to define the Web Crypto API as a *purely* synchronous API, but which can *only* be accessed from Web Workers?

This effectively leaves the asynchronous semantics up to applications to implement, by forcing them to use web workers. However, it allows the exposed surface of the API to be significantly reduced, as well as easier specification of the state machines.

A "complementary" synchronous API, as has been expressed as desired, is more likely a complete rethinking and re-implementation of the API.

This is, to some degree, also related to ISSUE-18, since exposing cryptographic transforms via the various proposed streaming APIs also implies asynchronicity, but with a more consistent programming model to existing web platform APIs.