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

On Mar 6, 2014 9:13 PM, "Alexey Proskuryakov" <ap@webkit.org> wrote:
>
> (re-sent from correct address)
>
> As an implementor, I'm fine with exporting into an ArrayBuffer, as well
as with importing from buffers. This is consistent with other formats, and
- especially when importing - nicely avoids any complications that could
arise while ingesting arbitrary JavaScript objects with their getters,
loops and such.
>

Can you explain this?

The complications are either addressed by WebIDL - in which case, they
don't apply - or they equally apply to our use of the Algorithm dictionary,
which means we have to solve them independent of this change.

ArrayBuffer is natural for ASN.1 types because they are byte oriented. JWK
is object oriented, and does not have the same formatting concerns that
ASN.1 has.

Having implemented two ASN.1 parsers in EcmaScript, and having worked with
JWK now, it continues to feel unnatural and non-intuitive that we express
JWKs as ArrayBuffers.

> If there is value in exporting to a JS object, it may indeed be that the
change is best to discuss after entering LC, when more people join the
discussion.

We already entered LC, after it was decided on Monday's telecon. This
thread is trying to put forward a concrete proposal, as was requested on
the call entering LC.

>
> - WBR, Alexey Proskuryakov
>
> 06 марта 2014 г., в 20:51, Mark Watson <watsonm@netflix.com> написал(а):
>
>> 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.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.
>
>
>
> - WBR, Alexey Proskuryakov
>
>