Re: WebCrypto API Developers Feedback

Guys,

Before you conclude that certificates are not supported I think you must specify what that really means.

A certificate is just a blob and could (as I understand at least) easily be stored in IndexDB so that it is accessible by an application using a matching private key created with Web Crypto.

If you on the other hand are thinking about _existing_ certificates including those that are stored in smart cards that's an entirely different thing which is currently not supported.

So which is it?

Anders

On 2013-03-14 06:24, Mountie Lee wrote:
> Hi.
> let me add my comment for your questions.
>
>
> On Thu, Mar 14, 2013 at 1:53 PM, Matthias Dugué <mdugue@clever-age.com <mailto:mdugue@clever-age.com>> wrote:
>
>     Dear WebCrypto WG members,
>
>     We are web developers, working in a web agency for various clients and various projects, from institutional to e-commerce websites.
>
>     We looked very closely into the WebCrypto API. Here are some thoughts, from our point of view:
>
>     In our opinion, nowadays, the low-level API requires some skills that the average developer doesn't have, which makes us think the high-level API is even more relevant and should be delivered quickly. Admittedly, it is a low-level API, but this makes it hard to use for a broad spectrum of web developers, mostly because of its permissive nature with many security choices, namely algorithms. A lot of us don't understand the implications of these choices, and think the learning curve is too steep.
>
> currently no consensus for high-level API.
> some member need it 
> but
> some member (like me) think do not need it.
> because the higher-level API can be contributed by 3rd party community (jQuery team will be good example)
>
>     While recommending a set of algorithms to implement, the low-level API does not guarantee a consistent implementation across browsers, which may generate reluctance in adoption. We fear that some browser editors will refuse to implement some algorithms due to their policies or technical difficulty, which will create a fragmented support, like the one we see today with the |<video>| codecs. 
>
>     Considering the key support and access, the fact that low-level API allows to retrieve a key which is not present in the browser environment (and thus create an error) will be confusing. We believe it would be preferable not to present a key whose material is not available, rather than offering to use it but throw an error when trying to access it. This reminds us of the |<video>| support and its |canPlayType()| method (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-navigator-canplaytype), that can return /probably/ if the media is playable, which is better than /maybe/ but worse than /yes/… Please, we need strong support when we need to deal with APIs, not /probably/ support! (-/is the key available ?/ -/probably/…)
>
> similar issues (http://www.w3.org/2012/webcrypto/track/actions/61) were also raised in previous F2F meeting.
> and my answer is some testing code is enough in lower level.
> your example "canPlayType()" also belong to high-level.
>  
>
>     Finally, the use case for certificate management is missing (as a simple and attractive means to implement the user/application authentication). We're very impatient to see the outcome of your efforts to bring us a robust API to build crypto methods. But, as web applications developers, our first emergency is a simple to use and robust API, to deal with certificates/authentication, in order to prevent the security hole that is currently the login/password couple.
>
> certificate management issue is one of secondary issues.
> I expect a draft version of certificate as a different document from current API spec will be suggested working group soon.
> My team is preparing the proposals and you can review and add your comment.
>  
>
>     Thanks a lot for your work and your interest in reading this email, we'll be closely following your drafts!
>
>
>     Matthias Dugué (@madsgraphics)
>
>     Nicolas Hoizey (@nhoizey)
>
>
>
>     -- 
>     Matthias DUGUÉ - http://www.clever-age.com/
>     Agence de Paris
>     Mobile : +33 6 13 12 73 75
>     Tél. +33 1 53 34 66 10
>
>     Clever Age - /Digital Architecture/
>     *Clever Garden - /Digital Landscape/*
>     Clever Presence - /Digital Running/
>
>
>
>
> -- 
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net>
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>
>
>
>