- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 4 Dec 2015 19:47:30 +1100
- To: Travis Leithead <travis.leithead@microsoft.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
On 1 December 2015 at 09:21, Travis Leithead <travis.leithead@microsoft.com> wrote: > Keygen and client certificates document: > http://w3ctag.github.io/client-certificates/ Does the TAG have consensus that <keygen> (and friends) is worth replacing? It seems like there are plenty of approaches that can support similar use cases, some of which have considerably more momentum (see Fido for instance). Is anyone signed up to do work on this? The document is unclear on what recommendation it makes regarding <keygen>-and-co right now. I could infer from all the activity that the subtext is a plea to retain the busted feature until a replacement is ready, but that's not clear to me from reading the document. I think that's a very important part of the statement. If the TAG has consensus on this point, I'd like to hear that. I'm disappointed that the TAG thinks that user permission is all that is needed to install a cross origin correlator. I realize that this is a highly contentious aspect of <keygen>: very important to some, one of the worst aspects to others. Either way, I don't think that there is any question you could sensibly ask a user that would convince me that the answer you got constituted informed consent. On a less serious note, I think that the characterization of CryptoKey is inaccurate. An asymmetric Crypto-Key with an unexportable private key might be usable for authentication, though other forms are definitely unsuitable. The opt-in protection isn't therefore a non-issue. I also believe that it is possible to generate keys in secure storage with the WebCrypto API (Firefox might already if there is a suitable device, but I'm not sure).
Received on Friday, 4 December 2015 08:47:59 UTC