Re: Web Cryptography Use Cases For Review

Hi.
following is the description for banking usecase.
it is described by considering certificate that the draft is not yet posted
WG.
so code example is missing.

by getting consensus for certificate, the usecase description can be
modified later.

PS) HongGilDong is traditionally more famous than PSY.
-----------------------

HongGilDong want to issue certificate that will be used online banking.
he visit physical bank branch
and retrieve reference number and approval code by face to face
verification of bank staff.
the reference number is used to track certificate enrollment process
for multiple days.

HongGilDong visit bank website (ra.gangnambank.com)
he generate key pair
and send the public key, reference number, approval code and other
parameters to bank RA(Registry Authority) center.
bank RA server forward the request to CA and return the certificate
signed by CA to user agent of HongGilDong

when he want to wire fund online
he enter some authentication codes (OTP, password or other
authentication methods promised between bank and account holder)
he generate digital signature for agreement document with his private
key binded to certificate issued by trusted CA
also he envelop the signed document with certificate of bank
and send enveloped message to bank

when he want to revoke certificate,
he generate digital signature for revoke request document with his private key
also he envelop the signed document with certificate of bank.
and send enveloped message to bank.
bank forward the revoke request to CA
CA add the certificate to CRL that will be check later by CRL
Distribution Point of certificate.



On Wed, Dec 19, 2012 at 7:03 AM, Arun Ranganathan <arun@mozilla.com> wrote:

> 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
>
>
>
>


-- 
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