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

On Tue, Mar 11, 2014 at 6: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.
>
>> If we support parallel formats, it should be because we believe the
>> ArrayBuffer case will be as significant a use case as with Object.
>>
> No, it's sufficient that they are both significant and useful. They don't
> need parity.
>
>> In either event, if we do support both, I believe the ArrayBuffer case
>> should be separately named (eg: JWKS) - precisely because JWK will
>> naturally yield or be manipulated as Objects, not octets, within JS.
>>
> The J in JWK stands for JSON. JSON is a wire format. Seems obvious that
> format "jwk" should produce a JWK, not a Javascript representation of one.
>
>> You keep saying "written to or read from a wire protocol", so I'd simply
>> ask that you back that assertion up with script demonstrating this use case.
>>
> This is what our application does today. I'll see if I can extract the
> relevant code.
>
> ...Mark
>


Mark, do you have any update on providing a concrete use case where the
ArrayBuffer containing a UTF-8 JSON byte sequence is demonstrably better,
simpler, or easier?

I've already laid out a number of reasons why the providing an actual
Javascript/IDL object
- Aligns with developers expectations of web APIs
- Minimizes the need for implementations to make unnecessary
copies/translations of data
- Avoids complexity (absent Encoding support) or verbosity (with Encoding
support)
- Integrates better with other platform APIs, such as
postMessage()/MessageChannel(), Web Sockets, JSON.parse(), and - notably,
XMLHttpRequest

You're arguing that the default be kept as ArrayBuffer for a use case that
you haven't shared or demonstrated, so it would be great if you can
actually show what the benefits are - as well as the comparable risk/harm
from requiring developers' that wish to use ArrayBuffer to go through the
additional steps.

Our experience in using the API for new code - including just writing
sample code - is that returning an object literal is far more friendly to
developers and users. Equally, the belief is that supporting multiple
formats is overall detrimental (API complexity), especially when the API
can be polyfilled [which is not the case for pkcs8/spki + wrap/unwrap,
which is why we have them in the first place]

+cc Boris, in the event there are intricacies of WebIDL that are being
overlooked here.