- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Mon, 13 Aug 2012 11:42:02 +0200
- To: Mountie Lee <mountie.lee@mw2.or.kr>
- CC: public-webcrypto-comments@w3.org
On 2012-08-13 11:22, Mountie Lee wrote: > Hi. > I'm not requesting more functions. > > it is the recommendation for adding use case. Hi Mountie, I don't understand the use-case. Most important: What is (in your opinion) missing today? How do clients get the certificates? What should trusted mean for the API? Regards, Anders > > regards > mountie. > > On Mon, Aug 13, 2012 at 5:40 PM, Anders Rundgren <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote: > > On 2012-08-13 10:08, Mountie Lee wrote: > > Hi. > > I meant > > CA can issue personal certificate ONCE with strong identity validation. > > I did not though two factor authentication or others PER USE. > > > > I can search http://www.symantec.com/verisign/digital-id > > but the cert is not enough to trust the personal identity. > > > > just I expect the new ca service like "Digital ID with Extended Validation" as use case. > > because of web crypto API. > > Hi Mountie, > I'm not sure what function you are requesting. > > Extended Validation is a CA policy for server certificates that are supposed to be "automatically" highly trusted by user agents. > It is not possible to translate this to client certificates because the relying party is not your platform/user agent/web browser/etc. It is another system > > I don't think that even the concept of trusted personal identity is generally acknowledged. > This tends to be rather local, national or community-based. > > I have a company certificate. It is trusted within the company since it was internally issued using an approved process. However, outside of the company it is unknown (non-trusted). > > Best regards, > Anders > > > > > best regards > > mountie. > > > > > > On Mon, Aug 13, 2012 at 4:35 PM, Anders Rundgren <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com> <mailto:anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>>> wrote: > > > > On 2012-08-13 07:46, Mountie Lee wrote: > > > I think following use case can be considered. > > > > > > CA issues strong personal identity certificates. > > > it can be equivalent level to EVSSL on server side. > > > > > > current personal certificate issued by CA is just checking email validity. > > > > > > if web crypto API is widely accepted in major user agents > > > certificate in user agents will have more functionality by using API. > > > > > > as a CA, they can consider to issue new type of certificate with strong personal identity validation. > > > > Hi Mountie, > > > > Certificate provisioning is AFAIK outside of WebCrypto scope. > > > > Banks and government agencies in the EU currently deploy their own software for provisioning since none of the user agents out there support provisioning of two-factor (key + PIN) authentication tokens [1]. > > > > Well, this wasn't entirely correct. When there is a *business incentive* to support provisioning of two-factor tokens, it is (of course) honored: > > http://googlecommerce.blogspot.co.uk/2012/08/use-any-credit-or-debit-card-with.html > > > > Regards, > > Anders > > > > 1] If you only need a client certificate and HTTPS you can use existing schemes like <keygen> and "CertEnroll". > > > > > > > > regards > > > mountie. > > > > > > ======================================= > > > PayGate Inc. > > > THE STANDARD FOR ONLINE PAYMENT > > > for Korea, Japan, China, and the World > > > > > > > > > > > > > > > > > > > > ======================================= > > PayGate Inc. > > THE STANDARD FOR ONLINE PAYMENT > > for Korea, Japan, China, and the World > > > > > > > > > > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > for Korea, Japan, China, and the World > > > >
Received on Monday, 13 August 2012 09:42:40 UTC