about deprecating <keygen>

In case you missed the starting thread…
Regards,
Virginie


From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: mercredi 2 septembre 2015 04:08
To: TAG List; Ian Hickson
Subject: Re: [whatwg] deprecating <keygen>



On 2 September 2015 at 00:22, Melvin Carvalho <melvincarvalho@gmail.com<mailto:melvincarvalho@gmail.com>> wrote:
FYI:
There was a recent discussion about deprecating an existing HTML element (keygen) from the w3c and/or whatwg specs, a time line for doing so.  I believe timbl suggested putting it on the radar of the tag, so I thought I'd give it a try.
The keygen element is currently in use.  There were some reasonable arguments, imho, both for and against.
I think there was an effort create an argument and time line for deprecation, that various stake holders could be comfortable with, and having an adequate replacement.
I think there was a concern that the communication streams were not as well targeted as they could have been, spread over mailing list, google groups, github issues, pull requests etc.  With the arguments as to what the alternatives would be for current implementations not 100% clear.  At the same time pull requests were made to various specs.  And changes to wikis with deprecation disclaimers, over a relatively short space of time.
I think an argument was that major industry players are backing the work done at FIDO alliance, to be an alternative to existing work.  However, it's not clear the FIDO spec is complete and will be a like for like replacement.  From what I could gather the latest feeling was that the element is at risk and could be deprecated in 12-18 months based on current projections, and that implementors should be warned.  There were also good suggestions about in the mean time improving the existing API and user interfaces.

Perhaps this could be a good case study for the tag, in terms of optimizing process and communications, for this and future changes.

Ah looks like timbl raised this already.  Feel free to skip this mail unless the details are of interest :)



---------- Forwarded message ----------
From: Ian Hickson <ian@hixie.ch<mailto:ian@hixie.ch>>
Date: 1 September 2015 at 19:56
Subject: Re: [whatwg] deprecating <keygen>
To: "henry.story@bblfish.net<mailto:henry.story@bblfish.net>" <henry.story@bblfish.net<mailto:henry.story@bblfish.net>>
Cc: whatwg@whatwg.org<mailto:whatwg@whatwg.org>


On Tue, 1 Sep 2015, henry.story@bblfish.net<mailto:henry.story@bblfish.net> wrote:
>
> As the WhatWG only recenly moved to Github members here may not have
> noticed that <keygen> has been deprecated.
>
> I opened https://github.com/whatwg/html/issues/67 to give space for the
> discussion. It is a pitty that this was closed so quickly ( within an
> hour ) without giving members and the public ( the users of the web )
> time to comment nor for their voice to be heard.
>
> This is a complex issue that involves many different levels of
> expertise, and it should not be handled so lightly.

The spec just reflects implementations. The majority of implementations of
<keygen> (by usage) have said they want to drop it, and the other major
implementation has never supported it. The element was originally (and for
many years) purely a mostly-undocumented proprietary extension; at the
time it was invented, the HTML spec was edited by the W3C and the W3C did
not add it (they only ended up speccing it in their most recent HTML spec
because they forked the WHATWG's spec which did define it -- indeed, even
then, it was something that W3C HTML working group members argued should
not have been included). It was only added to the WHATWG spec because one
of the browser vendors said they could not remove support for it due to
usage by enterprise customers; that browser vendor is now amongst one of
the ones wanting to drop it.

As far as I can tell, therefore, things here are working exactly as one
should expect.

It's worth noting that <keygen> is a pretty terrible API. I recommend
approaching the groups writing new cryptography APIs, explaining your use
cases, and making sure they are supported in up-and-coming, more widely
supported, more secure, and more well-thought-out APIs.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.