Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer

On Fri, Mar 7, 2014 at 6:59 PM, Ryan Sleevi <sleevi@google.com> wrote:

> The argument that wrap/unwrap should dictate format is a particularly weak
> one
>
That's not what I said.

Your statement pre-supposes that we support one format or the other. But
actually, we could support both. Supporting wrap / unwrap requires that,
internally, the implementation is capable of supporting JWK, but does not
say anything about what else it might support (such as JS object
representation of a JWK as you propose).

> , given the fact that
> 1) there is little interoperability guaranteed by the API
>
In what sense ? You need to substantiate this.

> 2) the *only* party that had requested wrap/unwrap has been Netflix, while
> multiple parties and use cases make clear they will be using JWK
>
We are using JWK - see below.

> 3) the whole point of the any type is to allow the most useful and
> appropriate return
>
True, but I fail to see the impact of this point here.

> The object being returned by exporting jwk is not, by definition, a JWK.
>
This is wrong. What we are returning now is, by definition, exactly a
"JWK". JSON is a serialization format, exactly like ASN.1 or XML. The fact
that JSON was "discovered" (as Cockcroft has it) in the Javascript object
literal format is irrelevant here - it is no longer that. ASN.1 and XML can
be represented as Javascript objects just as easily as JSON can.

I am not at all saying that returning a JWK (or anything else) in the form
of a Javascript object is a bad idea. It may be a great idea that we should
consider. But supporting JWK directly - as we do now - is also a great idea
which, incidentally, has been proven through multiple interoperable
implementations and live deployment. The javascript object option has no
such implementation or deployment evidence.

So, by all means let's discuss introducing a new option. But there's no
reason to consider removing an existing successful one. They are not
mutually exclusive.

> We also have gained new insight into the uses and use cases, and I believe
> they strongly support the argument for returning a more meaningful object
> by default.
>
Can you elaborate on the "new insight" ?

> The *only* factor that should weigh in at this time - before LC, before
> any implementations have shipped, is "What is right for the user" - and I
> do not believe that an ArrayBuffer - that has to be manually copied and
> expanded to UTF-16 as a DOMString to JSON.parse it - is right for users.
>
"Users", in the priority of constituencies, are the users of websites who
would never see these details.

I believe you are actually referring to web developers. Here, the question
is whether the site is going to hand the JWK off into a wire protocol, or
whether there is some local manipulation required first. The answer is
"both". I agree there is a marginal complexity difference between those two
use cases and the difference skews in opposite directions if API returns
either JSON or a Javascript object.

The difference is marginal, since conversion between the two formats is
straightforward. Nevertheless, as I said, internally WebCrypto needs to
support the serialized version to support wrap/unwrap. And this has been
stable in our API for some time.

So, again, I would argue that the question we should address is whether to
introduce a new capability to import / export Javascript object
representations of a JWK (or the ASN.1 structures for that matter). That
does not need to be accompanied by removing the existing, stable,
capability to import / export JWK directly.

> Just look at the amount of code to turn it into a JS object versus
> converting the object to a string to see the unnecessary complexity you're
> advocating.
>
I'm advocating the route where the developer can choose to get the format
they want directly, which is by far the least complex for all use-cases.
IIUC, you're advocating a route which would make generation of an actual
JWK more complex and along the way remove completely the possibility to
wrap / unwrap JWKs.

The idea of a new import / export format that is a Javascript object
representation of a JWK is a perfectly reasonable Last Call comment. Let's
put it in that bucket with the many other things that I am sure will come
up in Last Call.

...Mark



> On Mar 7, 2014 4:59 PM, <bugzilla@jessica.w3.org> wrote:
>
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24963
>>
>> --- Comment #2 from Mark Watson <watsonm@netflix.com> ---
>> As per my comment on the mailing list, I disagree.
>>
>> Serialized output aligns with the other formats and is necessary in any
>> case
>> for wrap/unwrap. We discussed and rejected providing object input / output
>> instead some time ago and the reasons discussed then still apply now.
>>
>> We should consider in Last Call whether to *add* the capability to import
>> /
>> export in object format. This would be an additional key format (e.g.
>> "jwk-js").
>>
>>
>> --
>> You are receiving this mail because:
>> You are the assignee for the bug.
>> You reported the bug.
>>
>