W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2014

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 13 Jul 2014 01:06:25 -0400
Message-ID: <53C213D1.9040607@mit.edu>
To: Ryan Sleevi <sleevi@google.com>
CC: public-webcrypto@w3.org
On 7/13/14, 12:10 AM, Ryan Sleevi wrote:
> That is the definition of reflects - i.e. what immediately follows the
> comma.

The part that follows the comma doesn't actually define the behavior sanely.

I mean, for the [[algorithm]] case it's talking about "converting the 
interface" but there is no interface involved.

> 1 - you can't modify what usages returns (short of overriding the getter)

Can't modify in what sense?  Can't modify the resulting object?  Why 
not, exactly?

> If you still feel it is ambiguous (and this was language that seemed to
> satisfy the TAG review

I can only assume people didn't read this very carefully.  :(

>, please open a bug and we can find better language.


>  > 1)  Clearly define in section 13.3 what sort of things are being
> stored in the internal slots.
> Please provide sample language, because its not actually clear what you
> are requesting.

I can't provide sample language, because I have no idea what behavior 
you want!

But let's assume that [[algorithm]] is supposed to store a Web IDL 
dictionary.  Then you should probably say something like this:

    All CryptoKey objects have internal slots named [[type]],
    [[extractable]], [[algorithm]], [[usages]], and [[handle]].

The [[type]] internal slot stores a DOMString.

The [[extractable]] internal slot stores a boolean.

The [[algorithm]] internal slot stores one of the dictionaries defined 
by this specification that inherit from KeyAlgorithm.  The exact type of 
dictionary stored depends on the value in the [[type]] internal slot 
(note: assuming it does, of course).

The [[usages]] internal slot stores ????

> Why is that desirable behaviour?

Why is what desirable behavior?  We want two things to be true:

1) foo.bar == foo.bar

tests true for our objects.  That means that a getter can't just return 
a new object every single time it's called.  This is why dictionaries 
aren't allowed as values of attributes in IDL, because they _do_ create 
a new object each time.  So if you want to return a dictionary, you want 
to convert it to an object and then cache that object somewhere.

2) Within the constraint imposed by #1, the behavior is defined sanely.

I'm quite sure whatever recommendations you got from the TAG did not 
include violating constraint #1.  It's pretty fundamental to how getters 
should behave: they should be idempotent unless something changes 
internal state between the two getter invocations.

Within that constraint, you have several options:

A) Return an instance of some interface.  Some people would argue that's 
the right thing here (e.g. see 
but that depends on what properties the return value should have.

B) Return an object produced from a Web IDL dictionary, accept that a 
web page can modify it (but not your internal state!) and thus somewhat 
shoot itself in the foot, in that what it sees from that point on via 
the getter will not match the internal state.  This is the option 
Domenic Denicola would advocate, I suspect,

C) Return an object produced from a Web IDL dictionary, freeze it before 
returning it.  This is in some ways a stronger readonlyness than option 
A, since it means no expandos.

There are probably other variants of (C) involving sealing instead of 
freezing and setting the attributes you youself define as non-writable.

>  > 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.
> Still not clear here.
> As currently written, they store IDL objects

As currently defined, nothing says what they store.  But OK, storing IDL 
objects here is good.  Then we just need to define what the getters do, 
and make sure that everything interacting with these internal slots is 
clear on them storing IDL objects.  For example, some of the spec prose 
talks about [[usages]] being an array, which makes people think that 
it's supposed to be an IDL array (which it's not) or a JS array (which 
it's also not).  It's meant to be a sequence, as far as I can tell.

> Structured Clone doesn't seem incompatible with this, given that
> structured clone algorithm itself makes use of such terminology.

Structured clone is not incompatible with anything; just have to define 
what it does on our members.

> (ImageData, File, and Blob are three objects that play particularly fast
> and lose with details, and they're the prime role models for this spec)

ImageData is perfectly well defined.  Structured cloning of ImageData 
explicitly creates a new one that has the same width and height and then 
structured clones the Uint8ClampedArray.  Structured cloning of 
Uint8ClampedArray is also clearly defined, so there is no problem.

The File/Blob spec is ... <sigh>.  Let's not copy it's problems.

Received on Sunday, 13 July 2014 05:06:55 UTC

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