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

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 00:33:34 UTC