Re: Web Cryptography Use Cases For Review

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