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

On Thu, Mar 6, 2014 at 6:14 PM, Mark Watson <watsonm@netflix.com> wrote:

> Ryan,
>
> I do not believe we should consider replacing the existing JSON
> import/export format with an object representation as proposed. The
> serialized JSON format has been stable for some time and aligns with the
> other formats which are also serialized objects as would be seen in a wire
> protocol.
>

Is it correct to say your argument is on two points:
1) You oppose change
2) You feel JWK is better suited as a wire format

To the point 1:
I do not believe that opposition purely on the grounds of "change" is a
good or encouraging sign, especially considering the aggressive push by you
to advance to Last Call. We have a priority of constituencies -
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies -
which is users > authors > implementors > specifiers > purity.

We have not been afraid to make other changes to "long stable" artifacts -
just look at the changes to KeyAlgorithm or to the handling of RSA keys for
two examples of changes for aspects of the spec that had been in even
_longer_.

We previously discussed this in
https://www.w3.org/2012/webcrypto/track/issues/14

You can see that even back then, there was positive reaction towards
exposing actual JWK-like objects.

Our choice of DOMString was largely arbitrary, to avoid the additional
specification of objects, and because wrap would need to work on the UTF-8
bytestring (hence no modification during wrapping)

Since naturally the question arises is "what new information exists to
cause us to revisit this?", I think the prime example is the case of ECDSA
keys and how "alg" is handled, for example. Likewise, in the development of
a JOSE JWS/JWE system, having the JWK as an actual object - for inclusion
within other dictionaries and message formatting - is far more valuable to
developers than requiring the additional parsing. This is especially true
for public key export of JWK, for which applications may process further or
embed in true messages as objects, rather than b64encoded UTF-8 strings.

To the point 2:
As you can see on ISSUE-14, this is not entirely true. Applications
developing JWE/JWS systems, or using the JWK types, are not necessarily
interchanging at a wire format level. If anything, JOSE is uniquely suited
to expose Keys as true Javascript objects.

The priority of "What makes sense for developers" should hopefully be clear
that one would expect JWK to be a Javascript object, especially when
obtained from a Javascript API, and that allows full mutation and
modification.


At this stage, we stand with no interoperable implementations, and a
clearly acknowledge spec that is in progress. I fail to see why we cannot
or should not revisit this issue, especially as implementation efforts have
begun, and the use cases continue to mature.


>
> Introducing a new object representation aligned with JWK is a great idea
> as an *additional* format, not a replacement - perhaps for a future version
> of the specification.
>
> ...Mark
>
> ---------- Forwarded message ----------
> From: <bugzilla@jessica.w3.org>
> Date: Thu, Mar 6, 2014 at 4:22 PM
> Subject: [Bug 24963] Export Key with "jwk" operations should return a JWK,
> rather than an ArrayBuffer
> To: watsonm@netflix.com
>
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24963
>
> --- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
> Bug filed based on this thread -
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0059.html
>
> Specifically,
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0063.html and
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0064.html
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
>