WebCrypto: Add WebKit API structure for keys.

Source/modules/crypto/Key.idl

Index: Source/modules/crypto/Key.idl
diff --git a/Source/modules/crypto/CryptoOperation.idl b/Source/modules/crypto/Key.idl
similarity index 83%
copy from Source/modules/crypto/CryptoOperation.idl
copy to Source/modules/crypto/Key.idl
index ba683a1b77ed663ff338999db41b9e1e439a4682..f66338594f971250d4e672e49bcf4987b8eb258b 100644
--- a/Source/modules/crypto/CryptoOperation.idl
+++ b/Source/modules/crypto/Key.idl
@@ -28,8 +28,27 @@
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+enum KeyType {
+    "secret",
+    "public",
+    "private"
+};
+
+enum KeyUsage {
+    "encrypt",
+    "decrypt",
+    "sign",
+    "verify",
+    "derive",
+    "wrap",
+    "unwrap"
+};
+
 [
     NoInterfaceObject,
-] interface CryptoOperation {
+] interface Key {
+    readonly attribute KeyType type;
+    readonly attribute boolean extractable;
     readonly attribute Algorithm algorithm;
+    readonly attribute KeyUsage[] keyUsage;

[abarth-chromium, 2013/07/03 18:01:41]

KeyUsage[]   ->  sequence<KeyUsage>  ?

Maybe what you've got here is right, but I'm not sure how foo[] works as a
readonly attribute.  For example, what if JS appends to the array?  Should that
change the keyUsage?

Also, what you've got here returns a new array each time.  Are we supposed to
return the same array object each time script reads the attribute (e.g.,
key.keyUsage === key.keyUsage) ?

Finally, isn't the word "key" here a bit of a stutter?  Why not just "usage"?

[eroman, 2013/07/03 19:18:06]

The web crypto spec currently defines it as an array. I will raise the question
of if it should be a sequence.

That said, Web IDL says that the elements of a read-only array cannot be changed
by the caller:

http://www.w3.org/TR/WebIDL/#idl-array

"Arrays can also be designated as being read only. User code cannot modify the
values of read only array elements. If an array is read only, then it is also
implicitly fixed length."

So this sounds in line with what we want. I will do some tests to verify that
this is what happens from our bindings generator and report back.

As far as not returning a new array each time: that is a good question. Do you
know how I can accomplish that from the blink bindings? Currently I am returning
a |Vector<String>|. However my expectation is that since Vector<> does not
extend ScriptWrappable, it cannot re-use the javascript array object even if I
were to return a |const Vector<String>&| (which is why I didn't bother caching
that vector).

Finally, I agree that the naming of "keyUsage" is not ideal. I have raised the
concern here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22561

 };