RE: Use of CryptoKey with polyfill

> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Monday, January 12, 2015 4:33 PM
> To: Jim Schaad
> Cc: Richard Barnes; public-webcrypto@w3.org
> Subject: Re: Use of CryptoKey with polyfill
> 
> Your first question is a bit confusing to me.
> 
> To restate: Are you asking if you can create your own instances of CryptoKey
> that refer to your object?
> 
> If so, no, you can't do that. It's spelled out here
> http://heycam.github.io/webidl/#dfn-platform-object

I thought that was what this said when I read it, but I was not clear that is what it was saying.

Thanks

Jim

> 
> Using the instanceof distinguisher is generally a poor trick anyways, and
> should be avoided. Ducktyping is your friend here :)
> 
> 
> On Mon, Jan 12, 2015 at 4:23 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
> > 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 01:02:02 UTC