- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 9 Oct 2012 13:54:25 -0700
- To: David Dahl <ddahl@mozilla.com>
- Cc: Jim Burrows <brons@eldacur.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>, Mountie Lee <mountie.lee@mw2.or.kr>
On Tue, Oct 9, 2012 at 8:33 AM, David Dahl <ddahl@mozilla.com> wrote: > 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 I thought previous discussions established the preferred form as "an API for JOSE" (Note that I have no especially strong feelings about this, other than I think it's the right choice because JOSE has made the algorithm trade-offs already) > > 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 20:54:53 UTC