Re: WebCrypto API Developers Feedback

On Wed, Mar 13, 2013 at 10:24 PM, Mountie Lee <mountie.lee@mw2.or.kr> 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>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.
>

True.


> some member need it
> but
> some member (like me) think do not need it.
>

That should not block it if other members find value.


>  because the higher-level API can be contributed by 3rd party community
> (jQuery team will be good example)
>

As a general rule, this argument does not work. The idea that "users will
consume a higher-level wrapper" most of the time means that your group is
either committing design malpractice by miscalculating the costs of the
wrappers or by excluding your largest motivating use-cases. It is design
failure not to deliver a feature that meets the needs of most of your
potential users.


>  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
>
>
>