Re: WebCrypto: JSON data encoding debate

On Mon, Mar 24, 2014 at 5:25 PM, Ryan Sleevi <sleevi@google.com> wrote:
> Since serialization to JWK may involve access to keying material, it's done
> asynchronously, since the underlying APIs may themselves block (particularly
> if/when talking about other types of cryptographic key storage). So defining
> toJSON on the Key object doesn't fly without preventing these.

You'd have keyToJWK as promise and then JWK would have a toJSON. But
yeah, maybe that's not needed. I'm entirely clear on the state of
overloading dictionaries in IDL and being able to distinguish them,
which is why having a dedicated object might be good.


> As for when ArrayBuffer, only one (very vocal) member has come out in
> support of it, but without a use case beyond "wire transport", so it's very
> difficult to evaluate the performance requirements. That said, "performance"
> appears to be a fairly weak argument, in light of
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0176.html

We could just add native support for Key to WebSocket and
XMLHttpRequest if people want that convenience. But it would be mostly
that as you point out that performance is not really impacted either
way.


> Am I/are we missing any considerations with respect to the JS object route
> that might impact this? For example, nuances of WebIDL or the environment?
> Boris Z. mentioned some of the things at
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0156.html

Ah right, that's what I was afraid of. That's why you might want to
have a dedicated object instead.


> Absent performance considerations, is there a good reason to support both
> methods? It seems more detrimental, from an API design smell, to give lots
> of little options.

Only if there's use cases. But since you can pass JSON to WebSocket
and XMLHttpRequest I don't really see what they are.


-- 
http://annevankesteren.nl/

Received on Monday, 24 March 2014 17:33:30 UTC