W3C home > Mailing lists > Public > www-tag@w3.org > June 2016

Re: removing keygen from HTML

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Wed, 1 Jun 2016 14:10:22 +0200
To: Chaals McCathie Nevile <chaals@yandex-team.ru>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <b425c2a7-4a0f-9f30-3f97-9f9209098e6a@gmail.com>
On 2016-05-30 11:40, Chaals McCathie Nevile wrote:
> Hi folks,
>
> there is an open issue [1] and open call for consensus [2] to remove
> keygen from HTML. Since the TAG, or its members, appear to have opinions
> about our spec, we'd be grateful to hear them.

If you look into the comments I think there are two fairly unrelated
issues here where removing keygen represents the less important (Microsoft
never bothered with keygen and iOS doesn't support keygen either).

So the core issue is rather that the TAG considers using client-certificates
in an origin-unconstrained (including user consent) fashion is "wrong".

The problem with this is that this concept already is firmly established and
in some places in the world indeed working quite good as well.  I don't think I'm
alone finding it quite handy being able to open any number of "doors" with just one key.

Few if any of these deployments rely on keygen, they rather use their
own take on certificate enrollment.  After the deprecation of browser plugins
which have had a big impact on the Web ecosystem, quite a bunch of these
deployments have switched to "Apps".

What's really missing is a down-to-earth description of how for example
WebAuthentication could support the multiple door scenario.

Anders

>
> cheers
>
> Chaals
>
> [1] https://github.com/w3c/html/issues/43
> [2] http://www.w3.org/mid/op.yhs220oos7agh9@widsith.local
>
Received on Wednesday, 1 June 2016 12:10:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:14 UTC