- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 25 Oct 2011 14:01:07 +0200
- To: "Harry Halpin" <hhalpin@w3.org>
- Cc: public-identity@w3.org
On 25 Oct 2011, at 13:17, Harry Halpin wrote: >> >> >> The neat enrollment scheme in iPhone which Apple didn't even mention > when <keygen> was standardized [*] by the W3C: > > > Please note that of course employees speak as individuals, but that your > examples rely on the mistaken assumption that <keygen> is a W3C > Recommendation, which it is not. <keygen> for many years (at least over a > decade) was supported only by Netscape and a source of confusion amongst > developers, and thus was avoided on the Web. 4 years ago when I started using keygen was supported by Opera, Firefox and Safari. Chrome initially did not, but then their TLS stack was just very new. Now it is supported everywhere on the desktop, except Microsoft that has an equivalent. For a lot of our (WebID XG) current use cases that seems good enough. keygen was avoided I think mostly because it was undocumented and because client certificates were not that useful, as they were thought to only be useable by one site - an thus not very interesting in comparison to simple cookies or passwords. Large corporations probably did find it very useful as well as the army as otherwise these features would not have stayed in the browsers. It turns out that with webid enabled certificates what is good for the army can now be good for everyone else. It is now in HTML5 and that is good. Better keygens would be great. I look forward to some simple use cases describing what I am missing. Perhaps an API function for creating keys would be better, but I am not sure why people in the web are so keen to move away from the declarative base of the web. Henry Social Web Architect http://bblfish.net/
Received on Tuesday, 25 October 2011 12:01:49 UTC