This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Web developers are offered a whole grab bag of crypto algorithms and primitives. This is not fundamentally problematic: there may be web developers who are deeply familiar with cryptography and have the wherewithall to reasonably evaluate which algorithms they should and should not be using. However, most web developers are not. Providing a recipe book of algorithms makes it unreasonably easy for web developers to pick wrong. In addition to making a wide range of primitives available to those who know what they're doing, the spec should take advantage of the considerable cryptographic expertise in the WG to construct secure, simple-to-use high-level primitives and recommend that most developers use them. DJB's NaCl library provides a good illustration of how to both provide secure default operations and make numerous primitives available for advanced applications.
DJB's NaCL library, while useful, is not suitable for generalized use cases. That is, it makes a specific set of tradeoffs and choices that are specific to the program it tries to solve. It's not alone in this. Other "high level" libraries make equally acceptable trade-offs - such as SJCL or KeyCzar. Finally, some libraries limit their cryptography to those specific to the problems they're trying to solve - like OTR or Pond, for which there is low-level cryptography involved, but it's conceptually abstracted away. Our charter makes it clear what our goals are, but perhaps more usefully, you can review the discussion around ISSUE 7 ( http://www.w3.org/2012/webcrypto/track/issues/7 ), which recorded a decision that goes back as far as summer of 2012 that a 'high level' API is not part of the deliverables. For what it's worth, of significantly more interest to the "Webby", "REST-y" community is something like the products of the IETF JOSE group - https://datatracker.ietf.org/wg/jose/charter/ - which provides for JSON-based signing and encryption, and which WebCrypto can be used to implement a high-level API abstraction for. Finally, the choice of a low-level API is additionally motivated by the reasons described at http://extensiblewebmanifesto.org/ , which includes a goal of standardizing "new low-level capabilities and building new features in terms of them", in part to "Allow browser vendors and library authors to iterate on libraries that provide developer-friendly, high-level APIs."