- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Thu, 20 Dec 2012 11:54:57 +0100
- 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. https://play.google.com/store/apps/details?id=com.bankid.bus 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. Anders 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