On 2015-09-02 12:12, GALINDO Virginie wrote:
In case you missed the starting thread…
No, I didn't miss it. If you look a bit deeper into this thread, this isn't really about <keygen>, it is rather about rejecting the eID use-case (a single ID to many and potentially independent relying parties). As a long-time user of eID [1] for logging in to various public-sector sites, I can attest that it works pretty good. Some 40% of the Swedish population is likely to agree if asked. The often cited privacy (tracking) issues are misunderstood since any serious association with a service provider will anyway require a verified e-mail address (= static long-lived Globally Unique IDentifier), or mobile phone number which (in practice) nullifies the privacy advantages of for example FIDO alliance's U2F. In fact, U2F's bound to SOP, makes this the preferred solution for giant IdPs that not only supply unified IDs, but also get a pretty good insight of your whereabouts on the Web. IMO, both FIDO and traditional client-side PKI are valid technologies on Web. Some countries (e.g. Germany) have laws which do not permit eIDs of the type described above. That is, "to eID or not to eID" could very well be left to the "market" rather than being hard-coded into the Web. There are probably 100 times more users of eID than of <keygen> so the latter can safely be put to rest some day in the future. Anders 1] Nowadays using an "App" since the browser-vendors also decided that signature plugins must not be used.
Regards, Virginie *From:*Melvin Carvalho [mailto:[email protected]] *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 <[email protected] <mailto:[email protected]>> 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* <[email protected] <mailto:[email protected]>> Date: 1 September 2015 at 19:56 Subject: Re: [whatwg] deprecating <keygen> To: "[email protected] <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> Cc: [email protected] <mailto:[email protected]> On Tue, 1 Sep 2015, [email protected] <mailto:[email protected]> 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.
