- From: Ryan Sleevi <sleevi@google.com>
- Date: Thu, 19 Jun 2014 12:42:50 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CACvaWvaev07TcZRrFrKR+YBm6TgUK_vG-Bjmi_wVhkZoBV=O9Q@mail.gmail.com>
On Thu, Jun 19, 2014 at 12:22 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 6/19/14, 3:09 PM, Ryan Sleevi wrote: > >> As noted in that document, we have tried to be compliant with the draft >> the WG sent to WGLC, on the basis of the signals provided by the WG on >> the stability and maturity of the specification. >> > > Just to be clear, does that include the large batch of spec changes that > happened 2-3 days ago? > > -Boris > > As noted on the linked document, the target has been the draft sent to WGLC. Of those recent updates, it includes those that were agreed upon prior to going to WGLC. That is, of note: https://dvcs.w3.org/hg/webcrypto-api/rev/3785b190bb2c - KeyUsage[] -> sequence<KeyUsage> https://dvcs.w3.org/hg/webcrypto-api/rev/a4cb70fcc0bb - SHA-256 for RSA-OAEP (which just wasn't specified how it worked with JWK, which JOSE since resolved) https://dvcs.w3.org/hg/webcrypto-api/rev/f61017a76a5d - JWK working on a dictionary (as discussed at length prior to LC) A number of changes in the updates, or pending updates, were/are to algorithms not implemented (yet) by Chromium - eg: DH and ECDH handling. Of those script-visible/user-visible changes not yet implemented, but are in progress for M-37: https://dvcs.w3.org/hg/webcrypto-api/rev/309495c2794e (KeyAlgorithm is still exposed as an IDL interface, albeit very subtly. We don't believe this represents a compat risk) https://dvcs.w3.org/hg/webcrypto-api/rev/4673a7019d7f (Key is still treated as an IDL interface, rather than CryptoKey) https://dvcs.w3.org/hg/webcrypto-api/rev/309495c2794e (KeyPair is still treated as an IDL interface, and thus cannot be used with postMessage) Other aspects, such as the copying/handling of CryptoOperationData - have been present in some form or another since the initial drafts (eg: the event-based draft's "process a buffer" language), and were already implemented out of necessity for Chromium's implementation.
Received on Thursday, 19 June 2014 19:43:18 UTC