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> 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]
> *Sent:* Thursday, March 6, 2014 12:44 PM
> *To:* Vijay Bharadwaj
> *Cc:* 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> 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.
>
>
>