RE: Use of CryptoKey with polyfill

Yes that makes sense to me.  I would have to do a more complete design to make sure that I understand it.

This does not however answer the first question that I had about putting the CryptoKey interface into the prototype chain.  That is needed for applications to use instanceof in a reliable manner.  I was originally thinking about using that as the distinguisher between JWK objects and keys returned from the system in my library code.

Jim


> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Monday, January 12, 2015 3:17 PM
> To: Richard Barnes
> Cc: Jim Schaad; public-webcrypto@w3.org
> Subject: Re: Use of CryptoKey with polyfill
> 
> No, he's talking about algorithm specific aspects of support, not generic
> support.
> 
> var promise = promise.reject(AnythingReally); if (window.crypto.subtle) {
>   promise = window.crypto.subtle.generateKey(...);
> }
> promise.then(
>    (key) => { return { 'key': key, 'interface': window.crypto.subtle },
>    (error) => { return yourPolyfill.generateKey(...).then(
>      (yourKey) => { return { 'key': yourKey, 'interface': window.crypto.subtle }
>    }).then((object) => {
>       return object.YourThing(object.key, ...)
>           .then(object.YourOtherThing(object.key, ...))
>           .then(object.YourFinalThing(...));
>     })
>     .then((result) => { doSomething(result); }); }
> 
> This is just a hacky solution that polyfills in support at the Promise level. In a
> 'production' grade code, you could create a Polyfill object that handled all
> algorithms / operations and used tricks like looking at whether key instanceof
> CryptoKey to know whether to defer to the underlying implementation (or
> any other approach you wished)
> 
> To explain the above example a bit more thoroughly - if the promise to
> generate the key was rejected (e.g. not supported), then the exception
> handler *for that promise* calls to yourPolyfill. yourPolyfill returns a promise
> to generate a key (which it may have done synchronously - e.g. via
> Promise.resolve(someSynchronousEvent) ), and then the success of that
> polyfill tells the rest of the promise chain to use your polyfill for whatever
> other things you need, rather than going to window.crypto.subtle.
> 
> The first promise is either immediately resolved (the (key) => {...}) when
> WebCrypto generates the key, or it can be a continuation (by virtue of
> returning a promise).
> 
> Hopefully that handwavy bit made sense.
> 
> On Mon, Jan 12, 2015 at 2:55 PM, Richard Barnes <rlb@ipv.sx> wrote:
> > W.r.t. 2: "if (window.crypto.subtle) { ... }", right?
> >
> > On Mon, Jan 12, 2015 at 10:37 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
> >>
> >> This may be an issue of ignorance on my part, if it is please excuse me.
> >>
> >>
> >>
> >> I am currently writing some code and have found that one or more of
> >> the algorithms that I need for it are not either on the currently
> >> supported or planned supported list for the browser that I am using.
> >> The way that I would normally solve this is by doing polyfill for the missing
> algorithms.
> >> In looking at this I have run into a couple of issues that I am not
> >> sure how to deal with.
> >>
> >>
> >>
> >> 1.       Is it possible to create a script size class which has the
> >> CryptoKey interface in the prototype chain?  This is one of two
> >> issues that I have (so far) discovered with the use of  instanceof
> >> CryptoKey  as a discriminator in writing my library code.  (The
> >> second is the fact that interfaces which are remoted from a different
> >> environment will have this be
> >> false.)  I have not actually tried to write the correct polyfill for
> >> this but have not yet found anything that would support it working
> >> either.  My first guess is that this might be very dependent on how
> >> the browser implements interfaces.
> >>
> >> 2.       If I want the polyfill to be conditional, then the normal
> >> approach I have seen in the past is to do some type of test on the feature
> >> and either define or not define the polyfill as appropriate.   I am not sure
> >> how this is going to work out with a Promises approach to everything.
> >> Currently the way that I would think about this is to generate a key
> >> with the algorithm in question.  However given that the result the
> >> promise would be pending unless the algorithm is not in the dictionary to
> be normalized.
> >> I am also not sure when the promises would be scheduled relative to
> >> the onload event   would they complete before the onload or would
> >> they be potentially afterwords.  My assumption is that the timing is
> >> totally arbitrary.  This means that the polyfill code may need to be
> >> called and started prior to it finding out if the feature it is
> >> filling in for actually exists in the base implementation.
> >>
> >>
> >>
> >> Help   Jim
> >>
> >>
> >
> >

Received on Tuesday, 13 January 2015 00:24:53 UTC