Re: removing keygen from HTML

> On 1 Jun 2016, at 14:10, Anders Rundgren =
<[email protected]> wrote:
>=20
> On 2016-05-30 11:40, Chaals McCathie Nevile wrote:
>> Hi folks,
>>=20
>> 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.
>=20
> 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).
>=20
> So the core issue is rather that the TAG considers using =
client-certificates
> in an origin-unconstrained (including user consent) fashion is =
"wrong".

I don't see where you get that from. The Client Certificate document =
published by=20
the TAG here

  http://w3ctag.github.io/client-certificates/

says that inserting a key into an OS keystore should not be done without
user consent, just like a web page should not be able to start the =
camera
on the computer without user consent, or be able to access the users geo=20=

location without her consent. All of that is well understood in fact, =
and
has not stopped browsers giving access to the camero or to geo location=20=

information on the device.
=20
> 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.
>=20

I think the TAG finding does not disagree with that position. Do you =
have text=20
you can point to that goes in that direction?

>=20
> 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".
>=20
> What's really missing is a down-to-earth description of how for =
example
> WebAuthentication could support the multiple door scenario.

I agree with you that the confusion about Single Origin Policy's =
applicability
to authentication across origins is what has stalled a lot of the work =
that would
have enabled  client certificates in browsers to be deployed to their =
full=20
capacity.

But to be fair, most of the browsers that have implemented client =
certificates have=20
held to this obvious restriction when dealing with using certificates =
accross origins.=20
The same is true about inserting a certificate into the OS level =
keystore, though perhaps
a lot of the browsers do not allow the user to easily specify if a =
certificate should
be only used for one origin or across origins... So improvements can be =
made.

So I welcome the TAG finding as it makes this obvious point clear.


>=20
> Anders
>=20
>>=20
>> cheers
>>=20
>> Chaals
>>=20
>> [1] https://github.com/w3c/html/issues/43
>> [2] http://www.w3.org/mid/[email protected]
>>=20
>=20
>=20