Re: Web Cryptography Use Cases For Review

Mountie,

I'd be happy to have you contribute to the use case :)  Currently, the API itself hasn't got enough "bits" with respect to certificates, but I'm happy to document a use case which relies more on certificates and key association with certificates.

What would be the best way to solicit your contribution?  Happy to include whatever you send in the draft in time for being PubReady :)

-- A*

On Dec 17, 2012, at 7:19 PM, Mountie Lee wrote:

> Hi.
> let me contribute to update Banking Transaction Use Cases.
> the current Banking Transaction Use Case is different from expected user behaviors.
> specially for certificate enrollment or certificate life cycle control issues.
> 
> 
> 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
>