Re: crypto-ISSUE-24: Defining a Synchronous API [Web Cryptography API]

We were thinking about this also, since a synchronous API is needed to use WebCrypto in onclose handlers, where the event loop is stopped immediately you exit the handler.

The existing API could be given a synchronous mode just by adding a boolean, "synchronous" to the close() method of CryptoOperation. If true, the close call would block until the operation was complete. Events would not be generated and the application would determine the outcome by inspecting the CryptoOperation attributes.

I'm not sure about requiring Web Workers. Everyone will need asynchronous versions, since these operations may take some time on some platforms (for example if the crypto is being done on a smartcard or similar). It doesn't seem a good idea to make everyone re-implement the same Web Workers wrapper. It also brings in Web Workers as an additional dependency for using this API and I am not sure they are universally available (on TVs for example ?).

…Mark


On Aug 20, 2012, at 7:45 AM, Web Cryptography Working Group Issue Tracker wrote:

> crypto-ISSUE-24: Defining a Synchronous API [Web Cryptography API]
> 
> http://www.w3.org/2012/webcrypto/track/issues/24
> 
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
> 
> 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.
> 
> 
> 
>

Received on Monday, 20 August 2012 16:10:06 UTC