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

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