W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

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

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 6 Mar 2014 20:20:14 -0800
Message-ID: <CAEnTvdDb4WGRqX-w=Q5PgOs944==ayuUEa23Bh8kuebxGOV-5A@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Thu, Mar 6, 2014 at 7:01 PM, Ryan Sleevi <sleevi@google.com> wrote:

> 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

No, I oppose revisiting things we discussed and decided on long ago at
this stage, where we are close to completion.

> 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.

I would not call my push to advance especially aggressive - we've been
dragging our feet filling in the boilerplate and resolving the last few
issues for a long time now. This specification is very close to having
multiple interoperable implementations (perhaps already has if you count
Polycrypt and NfWebCrypto) which is a milestone which goes with a *much*
more advanced formal status. What I find difficult to understand is the
strong push to delay and delay over minor issues. If we don't move this
forwards we won't get the deployment experience we need to turn it from a
nice piece of paper into a real part of the web platform.

> 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_.

The KeyAlgorithm change was a change with hardly any externally visible
effects (test cases didn't need to change to accommodate that). I'm not
sure what RSA change you are referring to.

> 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)

We didn't choose DOMString - the serializations are all passed accross the
APIs in ArrayBuffers. JSON is encoded in UTF-8.

> 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.

I'm not opposed to exposing the JWK as an object. Just that this should be
an additional capability and shouldn't be something that delays our Last
Call, especially since you raise it so late.


> 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.htmland
>> 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.
Received on Friday, 7 March 2014 04:20:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:41 UTC