Re: keygen and client-certificates document available

On 2015-11-30 23:21, Travis Leithead wrote:
>
> Hi folks!
>
> In September, Tim posted about <keygen> [1] which started a conversation about it on this list. The TAG has since met and discussed this topic, and we now have a document published with our latest thoughts. This document has our rough consensus at this point, and we additionally welcome feedback from you. As such, we’ve put the doc in a Repo [2] that has an issue tracker, so feel free to open issues against this document and we’ll do our best to resolve them. Thanks!
>
> Keygen and client certificates document: http://w3ctag.github.io/client-certificates/ <http://w3ctag.github.io/client-certificates/>
>
> [1] http://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html
>
> [2] https://github.com/w3ctag/client-certificates <https://github.com/w3ctag/client-certificates>
>

As a response to Tim Bernes-Lee's posting this appears to be an excellent document.

However, the removal of <keygen> only represents a very small tip of a much bigger iceberg which (among many other things) include a wide range of applications using client-based crypto-keys like the (in the EU) quite popular eID-schemes.  The latter have never bothered with <keygen> or Microsoft's counterpart "CertEnroll" since they don't meet their requirements.

Anyway, lots of applications (probably several thousand), recently hit a brick-wall when extensions like NPAPI and ActiveX were deprecated.  Fortunately, most of them found new life _outside of the Web_, typically in the form of Android and iPhone "Apps".

For eID (which "only" comprises some 100M users),  several people within W3C/FIDO sphere claim that FIDO/U2F compensates for this loss of functionality of the Web.  Rather than debating whether this is for real or not, Microsoft and Google should consider writing a document showing your vision of how such systems would be architected.

Regards,
Anders Rundgren
User and developer of eID-systems

Received on Tuesday, 1 December 2015 20:31:32 UTC