RE: Promise return types

OK in that case is it worth changing the specifications of exportKey?

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Thursday, March 6, 2014 1:43 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org
Subject: Re: Promise return types

Yeah, add JWK identifiers like kid or set "alg" in instances where we don't (eg: ECDSA, which is *not* bound to a hash in the manner that the RSA algs are). or x5u-etc. Or stick into a JWK Key Set.

On Thu, Mar 6, 2014 at 1:00 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
I totally understanding wanting to do other things like Stream for say encrypt and decrypt. It’s things like export that I have a harder time with.

From a programmer perspective, it seems to me that exported blobs would generally not be parsed locally, so requiring the JWK to be serialized is fine since it is something the script would have to do in any case. Do you see use cases where someone would get back a JWK object from exportKey and do something other than immediately serialize it?


From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
Sent: Thursday, March 6, 2014 12:44 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: Promise return types

The <any> types were actually part of the attempt to allow Microsoft (and others) to explore with other return types - such as Promise<Stream>

I do think it's weird that exportKey returns the serialized JWK - rather than an object that matches a JWK definition. As I understand it, this was largely because methods can only return Interfaces, and so we would have had to define JWK interface?

On Thu, Mar 6, 2014 at 11:22 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
Someone asked me a question recently that made me look more closely at our return types for the subtleCrypto functions. Should we look at tightening these up a bit instead of having them all be Promise<any>?

Specifically, is there any reason to have exportKey and wrapKey return Promise<any> instead of Promise<ArrayBuffer>? The way it’s set up now, it would be very tempting for someone adding a future algorithm to, say, return an object for the JWK export instead of serializing it first as all the existing algorithms do. This may develop into a hassle for programmers as they would have to track what each algorithm does for each format.