Re: Web Cryptography Use Cases For Review

Hi.
I have informed from Brad Hill of WebAppSec WG that
hash verification mechanism was discussed already
http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/0129.html

regards
mountie.

On Tue, Jan 15, 2013 at 1:13 AM, Arun Ranganathan <arun@mozilla.com> wrote:

> I agree that we should look at alternatives to eval() in the sample,
> including assuming we're retrieving a serialized JSON blob and maybe
> running a parse() on it.  Good nit! :)
>
> -- A*
>
> On Jan 14, 2013, at 8:31 AM, Mountie Lee wrote:
>
> Hi.
>
> when I review the example at
> https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html#data-integrity
>
> eval() is used.
>
> is there any alternatives instead of using eval()?
> because it can be evil.
>
> also the evaled script source will be located as inline
> and difficult to deploy CSP (Content Security Policy) of WebAppSec.
>
>
>
> On Tue, Dec 18, 2012 at 3:57 AM, Arun Ranganathan <arun@mozilla.com>wrote:
>
>> Greetings Web Crypto WG,
>>
>> The use cases document is ready for review:
>>
>> http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html
>>
>> It encompasses uses of the Web Crypto API *and* the Key Discovery API.  I
>> think it prudent to keep them together in terms of use cases, so that we
>> can document clearly what each seeks to achieve as *primary objectives.*
>>
>> This draft focuses on primary use cases, with the goal of breaking each
>> scenario down into features.  Additionally, wherever possible, the document
>> uses code snippets to illustrate the use of the feature in question.
>>
>> A few things of note:
>>
>> 1. This document collates *contributed* use cases (thanks in particular
>> to Mark Watson and Tantek Celik), with the use cases on our public Wiki
>> (namely http://www.w3.org/2012/webcrypto/wiki/Use_Cases ) as a starting
>> point.  We've now left that starting point behind, since I think the m.o.
>> of being as specific and detailed oriented as possible is the most useful
>> way to pursue use cases.  With that in mind, additional details on each of
>> these use cases are welcome, including contributions of illustrative sample
>> code :)
>>
>> 2. We don't have to agree on the merits of each use case.  For instance,
>> the pros and cons of PGP keys, and the practice of "publishing" them, are
>> well understood.  Our APIs might *enable* some practices that aren't
>> desirable, but I suspect people will do them anyway.  I do not consider
>> this document "recommendation track" although publishing it might be a
>> useful exercise.
>>
>> 3. Some useful features, including WRAP/UNWRAP, haven't got much API
>> backbone yet, and thus developers can "roll their own" subject to exposure
>> to the JavaScript environment.  It would be useful to cobble together a
>> wrap/unwrap that we agree is an interim solution using our existing API and
>> feature set, just as it would be useful to cobble together a key exchange
>> demonstration.  I know the editors have taken these on as further
>> challenges, and there are open issues w.r.t. these (e.g. ISSUE-35).
>>
>> 4. I do not consider this document done by a long shot :)  Feedback is
>> *strongly encouraged* as are contributions of further use cases with
>> details.
>>
>> I think we can include a section for pressing secondary use cases, after
>> we've aligned our primary ducks.
>>
>> Looking forward to getting feedback from all of you :)
>>
>> -- A*
>>
>>
>>
>>
>>
>
>
> --
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
>
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>
>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World