Jim:
I have been tinkering with a high-level design over here: https://github.com/daviddahl/web-crypto-ideas/blob/master/high-level-api.js
The simplest possible API is what I am going for: encryptAndSign(), verifyAndDecrypt() (as well as sign(), verify(), hash() and mac()), see: https://github.com/daviddahl/web-crypto-ideas/blob/master/high-level-api.idl
Please feel free to comment and/or send pull requests. I think a high-level API is also needed, one in which we do not focus on backward-compatibility and have much narrower use-cases.
Cheers,
David
----- Original Message -----
> From: "Jim Burrows" <brons@eldacur.com>
> To: "Mountie Lee" <mountie.lee@mw2.or.kr>
> Cc: "David Dahl" <ddahl@mozilla.com>, "Ryan Sleevi" <sleevi@google.com>, "Harry Halpin" <hhalpin@w3.org>, "Emily
> Stark" <estark@mit.edu>, "Wan-Teh Chang" <wtc@google.com>, public-webcrypto@w3.org, "GALINDO Virginie"
> <Virginie.GALINDO@gemalto.com>
> Sent: Tuesday, October 9, 2012 10:13:32 AM
> Subject: Re: Suggestions on high-level API - perhaps a meeting next week?
>
> [Third time's the charm. First attempt got caught by the "we need
> your
> permission to archive" filter and the second I did as a personal
> reply not
> to the list. Honest, after 4 decades or so, I promise to learn how to
> use
> email.]
>
> I have done contracting work in the last several months with two
> client
> companies who were building multi-platform suites of secure
> communications
> apps covering voice, text, data, email, alerting and video. My work
> has
> included JavaScript based development using SJCL. My clients have
> used
> Javascript-based code that I have developed for a few of purposes and
> have
> indicated an interest in using it for a number of others. The uses
> have
> included:
>
> * Jacketing captive JavaScript code in native-code apps to allow
> quick
> deployment of a client on a platform that does not yet have an
> app
> of its own.
> * Having an independently developed implementation of a
> communications
> client that is used for in-house testing of commercial
> products,
> allowing for the exercise of bugs and corner-cases not thought
> of
> by the creator of the original implementation.
> * Building of quick prototypes.
> * Development of a marginally-secure "beachhead" presence on a
> device
> whereby a secure native-code app can be delivered to a newly
> acquired device, and relying on out-of-band confirmation of
> probable identity.
> * File transfer using convergent encryption techniques.
> * Other more blue-sky applications.
>
> It is quite true that a secure pipe to an endpoint in an
> unverifiably-secure environment such as a web browser used for other
> purposes is of limited use due to the level of risk implicit in
> exposed
> nature of the endpoint, but there are often real world cases were
> there is
> significant operational value in having a secure pipe with one known
> secure
> end point, especially when you are in control of the risky end of the
> pipe.This can happen in in both the "beachhead" and controled-test
> environments, and is arguably a valid choice in terms of fast
> deployment to
> new or additional platforms if a sufficiently secure jacketing app
> can be
> quickly developed.
>
> I am, therefore, quite interested in seeing robust high-level APIs
> available, and thus my membership in this list, which is driven
> entirely by
> practical and not theoretical interests.
>