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

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.