W3C home > Mailing lists > Public > public-webcrypto@w3.org > January 2013

Re: Web Cryptography Use Cases For Review

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 14 Jan 2013 11:13:58 -0500
Cc: "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
Message-Id: <54D5BA15-49DB-4073-9B96-2CF9B1A654E5@mozilla.com>
To: Mountie Lee <mountie.lee@mw2.or.kr>
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
> 
Received on Monday, 14 January 2013 16:15:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:15 UTC