- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Tue, 11 Mar 2014 22:30:06 -0700
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-id: <7C420AF8-258C-4AD2-87E3-19F1FDA5EEFB@webkit.org>
Two new separate threads have been started in support of this idea within a week. I'm not sure if my comments have been addressed in either. - WBR, Alexey Proskuryakov 06 марта 2014 г., в 21:13, Alexey Proskuryakov <ap@webkit.org> написал(а): > (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. > > 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. > > - 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 > >
Received on Wednesday, 12 March 2014 05:30:38 UTC