Re: importKey doesn't seem to define handling of the keyData argument in some cases

On Tue, Jul 15, 2014 at 7:05 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/15/14, 8:43 PM, Ryan Sleevi wrote:
>
>> Because you endorsed it ;)
>> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0156.html
>>
>> ("You'll probably want to do "object" and manual coercion to dictionary
>> types)
>>
>> Rather than a litany of subtypes, they were folded all into JsonWebKey,
>> since all dictionary fields are optional anyway, the type distinction
>> didn't make sense. Perhaps your "object" comment was predicated upon
>> that design approach, but the union and choice of object (versus
>> dictionary) was a result of that thread.
>>
>
> Wait, wait.
>
> That mail was about a union that had multiple different dictionary types
> in it, no?  In that situation you have to use "object" and convert to the
> different dictionary types depending on whatever out-of-band information
> you have.  That was the context for my suggestion to use "object".
>
> But the actual spec as written folds all the dictionaries into one, as you
> say.  So then you can just use that dictionary type; you don't need the
> "object" games.
>
> -Boris
>

So, last call (for the WG) before I make the changes to the ED.

It sounds like we're in agreement to making it "(JsonWebKey or
CryptoOperationData)" (which is valid IDL since all three types are
distinguishable). JsonWebKey conversion will happen prior to method
invocation (as per Web IDL), rather than during the importKey steps, but
this "should" be an indistinguishable operation for authors (it's not,
because the broken-spec is more liberally worded, but thankfully sensibly
implemented).

And then the algorithm will be updated to ensure the type of the union
properly matches the type the key supplies.

If so, then https://www.w3.org/Bugs/Public/show_bug.cgi?id=26380 is the bug
for this.