- From: <bugzilla@jessica.w3.org>
- Date: Wed, 21 May 2014 01:05:05 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25842
Ryan Sleevi <sleevi@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |LATER
--- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
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."
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 21 May 2014 01:05:07 UTC