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

On Tue, Jul 15, 2014 at 10:11 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Consider an importKey call that passes "raw" as format and {} as keyData.
>  The spec says to clone the data, but https://dvcs.w3.org/hg/
> webcrypto-api/raw-file/tip/spec/Overview.html#concept-
> clone-CryptoOperationData isn't defined for things that aren't
> CryptoOperationData.
>
> Presumably importKey should be checking that keyData is a
> CryptoOperationData or some other union name that expands to the same thing
> (and throwing if not) before cloning it.
>

Yup. Definite bug. The JWK implicitly handles this (because it describes
converting keyData to a JsonWebKey, i.e. via WebIDL), but the other case
doesn't handle it.


>
> More generally, it's not clear to me why this argument is "object" instead
> of "(CryptoOperationData or JsonWebKey)", say.  The latter would mean
> conversion to the dictionary even if the format doesn't want a JsonWebKey,
> but that's OK: it would only affect erroneous usage cases which would
> simply throw after the conversion because they would detect that the type
> of the union doesn't match the passed-in format.
>
> -Boris
>
>
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.