Re: Clarification Requested

Looks like this changed after
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24963 -- before then the jwk
input to importKey were explicit bytes rather than a dictionary, so that
wording made sense as step (1) explicitly involved parsing:

    Let jwk be the result of running the "parse a JWK" algorithm over
keyData.

Following that change, I agree, the current wording ceased to be meaningful.

The preceding step (1) which "converts" to JsonWebKey *can* technically
fail if read in isolation. However there is a catch-all in section 14.3.9.6
that would prevent this:

    If the keyData parameter passed to the importKey method is not a
JsonWebKey dictionary, throw a TypeError.

So I would expect to get a TypeError in all such cases, and never hit the
DataError described in step (2).

While reviewing this, the language for JWK + unwrapKey() also suffers from
similar ambiguity.

In the unwrapKey() path the spec describes inflating UTF8-encoded bytes to
a dictionary (via JSON.parse()), and then implicitly converting that to a
JsonWebKey. There is no description of what to do if it is not a valid
JsonWebKey -- my assumption here is that "conversion" can fail when there
are type mismatches. Also in the unwrapKey "parse a jwk" thing, there are
implicitly the errors that JSON.parse() can throw (ie. SyntaxError), which
is perhaps not all that clear.

Personally I think it was clearer both in the spec and for consumers when
the 'jwk' format produced and consumed bytes rather than objects. From an
implementation standpoint I am still not sure what is really meant when
reading the JWK dictionary during importKey, since reading values from a
javascript object is not idempotent, and is sensitive to order, number of
times accessed, timings, etc in contrived edge cases.

On Mon, Apr 25, 2016 at 9:30 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> Looking at the import procedure for ECDH with format of "jwk", the first
> two lines are:
>
> 1. Let jwk be the JsonWebKey dictionary represented by keyData.
>
> 2. If an error occurred while parsing, then throw a DataError.
>
> It is not clear to me that the text here is clear.  Specifically, I don't
> see step #1 as being a parsing step so saying that an error occurring
> during parsing in step #2 seems odd.  From a testing point of view, I am
> not sure just what the error that is occurring in step #2 is supposed to
> be.  Are we saying that if there is an element which is not part of the
> JsonWebKey dictionary?  Is this left over from a point of time where we
> passed in a string rather than an object and the string was being parsed?
>
> Any clarifications would be helpful.
>
> Jim
>
>
>
>