Re: WorkerCrypto interface concerns from Microsoft

Just to close the loop on this -
https://dvcs.w3.org/hg/webcrypto-api/rev/9f1f378595fc should make it clear
that we're only exposing the Promises interface on WorkerCrypto - along
with the RandomSource.

It just means window.crypto behaves identical to worker.crypto, which
should address all use cases.

The previous blocking issues were:
1) Should we define sync interfaces
2) How do we handle multi-threaded Key access

We resolved point 1 by saying "No"
  - In the future, if we wish to do so, it can be as part of / extension to
the Promise interface" (eg: imagine a promise.wait() method)
We resolved point 2 by removing the Key Storage (long ago), allowing Keys
to be handled in IDB.
  - All cryptographic state is handled within the Promise, which isn't
transferrable between workers
  - Key tainting is no longer required, by virtue of moving the hashed
attributes into key generation, so we don't have synchronization risks there
  - Regardless, by virtue of the Promises() interface, implementations can
take their own approach to scheduling the work for promises




On Tue, Feb 25, 2014 at 9:56 AM, Israel Hilerio <israelh@microsoft.com>wrote:

>  Group,
>
>
>
> After yesterday’s call, I had an opportunity to get clarification from
> Ryan on the work related to the WorkerCrypto interface [1].  From my new
> understanding, the intent is to surface the SubtleCrypto interface and its
> async behavior to a Worker so that they can perform cryptographic
> operations as first-class citizens.  This approach won’t allow for any
> mutation of DOM objects.
>
>
>
> This new understanding removed my initial concern about the section. This
> seems very reasonable and I don’t see a need to put this section at Risk.
> However, I would like to see this clarification be part of the spec.
>
>
>
> Israel
>
>
>
> [1]
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#WorkerCrypto-interface
>
>
>