Spec for CryptoKey.algorithm and CryptoKey.usages doesn't really make sense

The IDL is:

   readonly attribute object algorithm;
   readonly attribute object usages;

and the prose is:

   algorithm
     Reflects the [[algorithm]] internal slot, converting the interface
     contained within [[algorithm]] to an ECMAScript object, as defined
     by [WEBIDL].
   usages
     Reflects the [[usages]] internal slot, converting the list of
     KeyUsages to an ECMAScript Array object, which indicates which
     cryptographic operations are permissible to be used with this key.

First of all, this doesn't really define the behavior.  For example, if 
I do .usages twice on the same CryptoKey, will I get the same object or 
different ones?  If I modify the .usages value I get and then structured 
clone the CryptoKey, will the clone pick up my modifications or not? 
"Reflects" is not defined anywhere, so it's not clear what these getters 
are supposed to be doing.

Note that section 13.5 seems to assume that the things stored in these 
slots are structured clonable, which is not obvious to me.  For example, 
[[algorithm]] seems to store a Web IDL dictionary, which is not 
something that structured cloning makes sense for.

I suggest that the following be done:

1)  Clearly define in section 13.3 what sort of things are being stored 
in the internal slots.

2)  Clearly define in 13.4 how the getters produce the thing they return 
from the thing stored in the internal slot.  If, as I expect, you want 
the returned values to behave nicely as JS objects but not propagate 
mutations to the CryptoKey, then what you actually want is to have extra 
internal slots (call them [[exposed_algorithm]] and [[exposed_usages]]), 
fill them on first get with a JS object version of whatever is in 
[[algorithm]]/[[usages] (the exact mechanism by which that JS object 
version is produced would need to be defined) and then just keep 
returning what's in the [[exposed_*]] slots.  But maybe the goal is some 
other sort of behavior?  It'd be good to understand what that goal is.

3)  Structured cloning should ignore the [[exposed_*]] internal slots. 
What it should do with the [[algorithm]] and [[usages]] internal slots 
depends on exactly what sort of things are stored in those slots; we can 
figure that out once we decide that part.

4)  If the [[algorithm]] and [[usages]] internal slots store JS objects, 
the exact way those objects are constructed needs to be defined, either 
by referencing Web IDL algorithms explicitly or in terms of ES 
operations.  Otherwise you'll likely get observable differences between 
implementations in terms of how they construct the objects.

-Boris

Received on Sunday, 13 July 2014 01:23:58 UTC