Latest editor's draft

Well, after a whirlwind of updates, not to mention a migration of
revision control systems, the latest Editor's Draft is live:

You can view it (and always view the latest ED) at
http://dvcs.w3.org/hg/webcrypto-api/raw-file/f5e8d9a3e18f/spec/Overview.html

You can view the log of each and every change at
https://dvcs.w3.org/hg/webcrypto-api/ . The short log is
https://dvcs.w3.org/hg/webcrypto-api/shortlog/22 , but the changelog
view is likely best. You can start at
https://dvcs.w3.org/hg/webcrypto-api/log/ca944b205467 to see when I
first imported from CVS. Use the navigation controls [ (0), +10, tip ]
to advance the log forward. There are 22 revisions in total.

Notable changes:
  - Removed the KeyStorage strawman, and instead provided text to show
it's still an area in discussion. This will likely be updated to point
to Mark's proposal RSN.
    - This also removed the Netflix use case, which I realize may be
troubling for some. My goal here was to avoid describing behaviour
that wasn't universally implemented. This use case is presently
captured in Arun's "What we wish to be able to accomplish" use cases
document at http://dvcs.w3.org/hg/webcrypto-usecases/ . I suspect that
this use case may make an ideal fit for Mark's proposal, in terms of
describing why exactly pre-provisioned keys also make sense.
  - KeyAttributes - gone! The explanation is in the log -
https://dvcs.w3.org/hg/webcrypto-api/rev/9baa26b28e78 - and more
description can be provided. This is, again, trying to avoid creating
Yet-Another-Web-Storage-Mechanism.
  - id, startDate, endDate, temporary - gone! See above, it's about
API consistency
  - out with PKCS#1 , in with PKCS#8 and subjectPublicKeyInfo - per F2F
  - Concat added as an algorithm - see
https://dvcs.w3.org/hg/webcrypto-api/rev/19613bbac7f8 for proposal

Finally, the biggest set of changes involved attempts to address the
very real usability and consistency concerns for the API.
Collectively, this has the API move more towards a Promises-style API
of objects that can either succeed or fail, and which execute
asynchronously, eventually returning a result. This includes the
ability to do hash/digest/encrypt/decrypt operations in a single call
(similar to existing JS crypto APIs), although it remains
asynchronous.

The easiest way to show this is with code, so see
https://dvcs.w3.org/hg/webcrypto-api/raw-file/f5e8d9a3e18f/spec/Overview.html#examples-section
for the updated examples.

There's still a *number* of things left unaddressed and underspecified
at this time, as I continue to focus first on the usability and
extensibility of the API. This under-specification of how certain
methods behave is not ideal, as it prevents implementation work from
starting, but I'm wanting to ensure that there is consensus (both from
within the group and from the public) as how the API behaves and how
it is extended (such as for custom Key objects/sources), before going
too far in the realm of specifying how user agents implement said
algorithms.

So please, begin taking a look, and expect a more nuanced overview on
our next call.

Received on Monday, 10 December 2012 09:10:46 UTC