- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Mon, 13 Aug 2012 13:32:18 +0200
- To: Mountie Lee <mountie.lee@mw2.or.kr>
- CC: public-webcrypto-comments@w3.org
Hi Mountie, I guess your use-case is really only "client certificates". This is already in the draft and in the charter (as secondary features). Anders On 2012-08-13 11:42, Anders Rundgren wrote: > 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 11:32:58 UTC