W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > December 2012

Certificate Enrollment. Re: Banking Transaction Use Cases

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Thu, 20 Dec 2012 11:54:57 +0100
Message-ID: <50D2EE81.1050201@telia.com>
To: Mountie Lee <mountie.lee@mw2.or.kr>
CC: Arun Ranganathan <aranganathan@mozilla.com>, David Dahl <ddahl@mozilla.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On 2012-12-20 03:29, Mountie Lee wrote:
I can tell you how it works in Sweden.

Scenario 1: Hard token
- The user go to their banks and gets a token created in a backend process.
- To actually use it requires download/installation of proprietary middleware
  that typically doesn't run on all platforms

Scenario 2: Soft token
The user surfs to the banks CA-site and
 - Download/installs proprietary middleware
 - Authenticates with an OTP token (standard stuff in the EU)
   and gets a certificate through a proprietary process which
   presumably does a PKCS #10.  The process also involves
   setting a PIN according to the bank's policy

Scenario 3: Mobile BankID
Similar to Scenario 2 but due to the inability to use browser plugins
in iOS and Android, based on proprierary "apps" with hard-coded URLs.


Important note: Neither the platform/browser key-store nor the enrollment
system (like <keygen>) are used in Scenario 2 and 3 since these (among
many things) do not support PINs.

The Google Wallet builds on an entirely different platform (no links whatsoever
to <keygen> and friends) which indeed supports "bank technology" and more.


To use it they need to install middleware and browser plugins which typically only works on some OSes.

> for certificate enrollment, it need sequence of operations.
> followings are the normal process in Korea.
> a) bank account holder visit physical bank office to issue digital certificate
> b) bank staff verify user identity by face to face meeting with ID card.
> c) bank staff give a token to user (the token is generated from bank RA system)
> d) user visit CA center(web site) and enter token and some other account related information
> e) private and public keys are generated by CA software ( normally ActiveX)
> f) CA software send Request to Issue Certificate message to CA server
> g) CA verify the token and other informations
> h) CA software receive the certificate and install to user agent or other internal keystore.
> the above processes are defined by CMP international standard ( http://en.wikipedia.org/wiki/Certificate_Management_Protocol )
> by WebCrypto API, we need to re-define whole processes and comparing the differences and possibilities.
Received on Thursday, 20 December 2012 10:55:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:49 UTC