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

Ryan,

I'm not opposed to making changes in LC, including this JWK one. In fact
I'm sure we will need to make changes. LC feedback could be far more
substantial than this JWK issue, which is actually pretty in terms of the
effect on users of the API (there is nothing that you can do with the API
now which couldn't trivially still be done if the object form of import /
export was also supported.)

What I'm opposed to is forever delaying LC over the fact that such changes
are possible.

...Mark


On Thu, Mar 6, 2014 at 8:37 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Thu, Mar 6, 2014 at 8:20 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>>
>> 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.
>>
>
> Isn't the point to gain feedback from users and implementors?
>
>
>>
>>
>>> 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.
>>
>
> Polycrypt and NfWebCrypto having implemented early drafts that the WG
> agreed was not the right approach.
>
> Neither have been updated to reflect any work on the draft.
>
> As was expressed on the call by Microsoft, Last Call within the Web Apps
> sector has typically reflects a much more advanced state than we're in - a
> belief that the spec is ready and that we're not going to be wasting the
> time of reviewers and the community by changing things further.
>
> It equally signifies a rubicon of compatibility - that as we go forward,
> our ability to change, to explore, and to make sure we're adequately
> serving the users of the Web Platform.
>
> Our last draft was published http://www.w3.org/TR/WebCryptoAPI/
>
> It reflects an API that is fundamentally different than what we have now.
> We have removed some features (eg: "multi-part operations"), significantly
> altered some (eg: the derivation of promises), and added significant new
> APIs (eg: deriveBits).
>
> Likewise, during this time, multiple vendors have been pursuing
> implementations, gaining implementation experience and validating that the
> API does _not_ require significant changes - a process strongly discouraged
> during/after Last Call.
>
> I think your characterization of "dragging out feet" is entirely unfair to
> these efforts.
>
>
>>
>>
>>
>>>  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.
>>
>
> The change to make the Hash as part of the creation, rather than the
> operation parameters.
>
> It remains to be seen whether or not ECDSA needs to make a similar change.
>
>
>>
>>
>>>
>>> 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.
>>
>> ...Mark
>>
>
> Mark,
>
> This is _exactly_ the time to raise it. It seems like you would equally
> oppose it if we received feedback to the same effect during LC, since it
> would be a change. That doesn't seem a positive sign for LC, or for
> soliciting feedback.
>
>
>>
>>
>>>
>>> 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.
>>>>
>>>>
>>>
>>
>