Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer

On Mar 11, 2014 11:33 PM, "Alexey Proskuryakov" <ap@webkit.org> wrote:
>
>
> 11 марта 2014 г., в 23:00, Ryan Sleevi <sleevi@google.com> написал(а):
>
>> > As an implementor, I'm fine with exporting into an ArrayBuffer, as
well as with importing from buffers. This is consistent with other formats,
and - especially when importing - nicely avoids any complications that
could arise while ingesting arbitrary JavaScript objects with their
getters, loops and such.
>> >
>>
>> Can you explain this?
>>
>> The complications are either addressed by WebIDL - in which case, they
don't apply - or they equally apply to our use of the Algorithm dictionary,
which means we have to solve them independent of this change.
>
> I see - so the proposal is to define dictionaries for each JWK kind, and
to rely on WebIDL's algorithm for converting between JS objects and WebIDL
objects.
>
> Looks like WebCrypto may be the only spec that will use dictionaries as
dictionary members, so this will put some non-trivial burden on
implementations. But at least it's defined somewhere.

We already have this with Algorithm (eg: a RsaHashedImportParams that takes
an Algorithm for hash).

Were you suggesting that WebIDL didn't allow this? The only thing I could
find was its prohibition on circular references of types, which we don't
have directly (eg: RsaHashedImportParams can't contain a
RsaHashedImportParams member).

The JWK import I proposed continues this pattern (although only in the case
of RSA, and only for multi prime). That's why I didn't understand your
concerns - presumably they have to be solved already for algorithm.

The export behavior does not declare concrete IDL types (eg: worrying about
prototype inheritance), since it follows WebIDL Section 4.2's behavior of
describing the explicit ES object. So you don't have any interface
complexities, nor worries about corruption of the JS environment (eg:
manipulation of object Prototypes)

>
> - WBR, Alexey Proskuryakov
>