Re: Suggestions on high-level API - perhaps a meeting next week?

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.
>

Received on Tuesday, 9 October 2012 15:34:08 UTC