Re: JWK import/export as ECMAScript objects, rather than ArrayBuffer

On Thu, Mar 27, 2014 at 11:10 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
> Sent from my iPhone
>
> On Mar 27, 2014, at 1:50 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
> On Mar 27, 2014 3:07 AM, "Mark Watson" <watsonm@netflix.com> wrote:
> >
> >
> >
> > Sent from my iPhone
> >
> > On Mar 27, 2014, at 1:19 AM, Ryan Sleevi <sleevi@google.com> wrote:
> >
> >>
> >>
> >>
> >> On Fri, Mar 21, 2014 at 7:23 PM, Richard Barnes <rlb@ipv.sx> wrote:
> >>>
> >>> On Fri, Mar 21, 2014 at 4:04 PM, Ryan Sleevi <sleevi@google.com>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Mar 21, 2014 at 12:59 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>> On Mar 21, 2014, at 12:41 PM, Richard Barnes <rlb@ipv.sx> wrote:
> >>>>>
> >>>>>> On Fri, Mar 21, 2014 at 1:17 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Mar 21, 2014 at 7:50 AM, Richard Barnes <rlb@ipv.sx>
> wrote:
> >>>>>>>>
> >>>>>>>> On Tue, Mar 11, 2014 at 9:08 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Mar 11, 2014 at 6:00 PM, Ryan Sleevi <sleevi@google.com>
> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mar 11, 2014 5:44 PM, "Mark Watson" <watsonm@netflix.com>
> wrote:
> >>>>>>>>>> >
> >>>>>>>>>> > Hi Ryan,
> >>>>>>>>>> >
> >>>>>>>>>> > This looks good with the following comments:
> >>>>>>>>>> >
> >>>>>>>>>> > (1) Why not add this capability, whilst keeping the existing
> JWK import / export ? For example add a new format "jwk-obj". This would
> keep things simple for the other use-case where the JWK is just being
> written to / read from a wire protocol. Supporting both is hardly arduous
> since UAs must support the serialization / de-serialization for wrap /
> unwrap anyway.
> >>>>>>>>>> >
> >>>>>>>>>>
> >>>>>>>>>> We should prioritize the common case. Dealing with ArrayBuffers
> for JSON or JS Objects is not the common case for any other Web API.
> >>>>>>>>>
> >>>>>>>>> We might disagree about which is the common case. Since we
> already have the actual JWKs (and several browsers have implemented these
> and they are being used) it seems sensible to add functionality here. There
> is no additional work to add rather than replace, so there is no need to
> prioritize.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> It seems abundantly silly to have two options here, when there's
> a trivial conversion between them.
> >>>>>>>>
> >>>>>>>> Object -> json.stringify() -> TextEncoder -> ABV
> >>>>>>>> ABV -> TextDecoder -> json.parse() -> Object
> >>>>>>>>
> >>>>>>>> Whichever one we choose here, a small JS shim can emulate the
> other.  So we should really just choose one.
> >>>>>>>
> >>>>>>>
> >>>>>>> This is fine if you have TextEncoder. It doesn't appear on
> caniuse.com. Does anyone have information about browser support of this ?
> >>>>>>
> >>>>>>
> >>>>>> Even if you don't have TextEncoder, it's a small polyfill.  See,
> e.g.:
> >>>>>> http://www.onicos.com/staff/iz/amuse/javascript/expert/utf.txt
> >>>>>> http://polycrypt.net/common/util.js
> >>>>>>
> >>>>>> Object -> json.stringify() -> utf16to8() -> somethingLike_str2abv()
> --> ABV
> >>>>>> ABV -> something_like_abv2str() -> utf8to16() -> json.parse() -->
> Object
> >>>>>
> >>>>>
> >>>>> How efficient is the polyfill for large messages ?
> >>>>>
> >>>>> ...Mark
> >>>>>
> >>>>
> >>>> Define 'large messages'. 512 bytes? 40K? 80K? 2MB?
> >>>>
> >>>
> >>> Out of curiosity, I made a little speed test and made some
> measurements (on my admittedly high-end laptop).
> >>> Test: http://www.ipv.sx/transcode-test/
> >>> Results: http://goo.gl/jAowJh
> >>>
> >>> TL;DR: All browsers tested could process 16KB in <=6ms and 256KB in
> <50ms.  20MB took a couple of seconds.
> >>>
> >>> But none of this matters, since we're talking about key packages,
> which are never going to be more than ~10KB.  So performance is not an
> issue.
> >>>
> >>> --Richard
> >>>
> >>
> >> Note, recently this issue was brought to the attention of the W3C TAG
> and there has been some discussion about this at
> http://lists.w3.org/Archives/Public/www-tag/2014Mar/0026.html
> >>
> >> There is still a lot of confusion about the use cases for the
> ArrayBuffer case, so hopefully Mark can provide the use case / sample code
> to demonstrate the pattern.
> >>
> >> Otherwise, it does seem like there is a general sentiment towards using
> 'proper' JavaScript objects, especially in light of the general uses of JWK.
> >>
> >> I'd like to make some degree of progress on this so we can close it out.
> >
> >
> > As I mentioned before, if support for TextEncoding is widespread or
> expected to be soon, then (as Richard says) there is no advantage in
> supporting both options, since conversion is trivial and efficient.
> >
> > In that case, I do not have an opinion on which option we should support
> (because conversion is trivial and efficient).
> >
> > So, what is the status of TextEncoding ?
> >
> > ...Mark
>
> Mark,
>
> Conversion is still trivial and efficient - for _your_ use case, without
> Encoding support.
>
> Put simply: Can you agree to live with this without that support, or will
> you raise a formal objection? If so, the WG *needs* to know why and how to
> resolve this.
>
> Holding this spec 'hostage' for Encoding support is not a viable path.
>
> This is certainly not an issue worthy of a formal objection and I've no
> intention of holding the spec hostage.
>
> I would like to know about the status of TextEncoding. Is it something
> that all browsers are considering implementing or is it something about
> which there is controversy? It's not listed on caniuse, which usually
> covers most mainstream stuff.
>
> I don't think it's necessary to have TextEncoding supported by browsers in
> the same timeframe as WebCrypto to go with the object approach, but I would
> feel more comfortable with the object approach if it was known that
> TextEncoding was at least 'coming soon to a browser near you.'
>

I'm confused as to why TextEncoding is still an issue here.  I though I had
posted some links to polyfills up-thread, and provided some data on their
efficiency.  Re-encoding strings from UTF-16 to UTF-8 is really not hard.

--Richard




>
> ...Mark
>