Re: WebCrypto API Developers Feedback

Hi.
let me add my comment for your questions.


On Thu, Mar 14, 2013 at 1:53 PM, Matthias Dugué <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

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World