W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

On a Futures-style API

From: Richard Barnes <rbarnes@bbn.com>
Date: Tue, 23 Apr 2013 10:43:04 -0700
Message-Id: <665A4B2C-2083-4B5F-9862-46B6F7E97563@bbn.com>
To: "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
As it happens, I did some thinking about what a Futures-style version of the API would look like.  

One key difference is that a Future represents the output of the function.  Instead of the callback getting a reference to the Operation (as event.target), it gets a new output object.  So we need to define what these outputs are.

It seems to me that there are three high-level types of output:

1. Ciphertexts (from encrypt / sign / digest): These objects need to have the output of the cryptographic process (the ciphertext data itself), as well as references to the parameters used to generate it.  That is, the algorithm/key fields that are on CryptoOperation today.

2. Plaintexts (from decrypt / verify)

3. Keys (from generateKey, etc.)

This taxonomy also provides kind of a nice structure for the various API methods.  Namely, the methods convert from one of these types to another.  So the primary input to the method is an object of the source type (e.g., a plaintext or ciphertext), and everything else is configuration for the conversion.

I've put together some notional IDL to sketch out how these concepts could turn into an API:
<https://docs.google.com/document/d/189K7BFE9jmNHyEerc5qac0T5l454WcC_v5tkFmjGpL4/edit?usp=sharing>

Hope this helps,
--Richard
Received on Tuesday, 23 April 2013 17:43:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC