W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

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

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 21 Mar 2014 13:04:05 -0700
Message-ID: <CACvaWvZT_bANXcQXBPivROj_f-mQ03SgfTF3Gqmw-y9kDpi79w@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Richard Barnes <rlb@ipv.sx>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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?
Received on Friday, 21 March 2014 20:04:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC