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

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.