On 9 Aug 2013, at 13:47, Norman Gray <nor...@astro.gla.ac.uk> wrote:
> > Henry, greetings. > > [replying only on public-lod] > > Bit of an essay, this one, because I've been mulling this over, since this > message appeared a couple of days ago... > > On 2013 Aug 8, at 16:14, Henry Story wrote: > >> On 7 Aug 2013, at 19:34, Nick Jennings <n...@silverbucket.net> wrote: >> >>> 1. Certificate Name: maybe there could be some examples of ways to name >>> your certificate. > [...] >> >> That's why it should be done by the server generating the certificate. >> The details are here: >> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#the-certificate > > I appreciate the logic here, and can see how it works technically smoothly > for the anticipated use-case (the one illustrated in the WebID video on the > webid.info front page). I don't think that's enough, however, because I > don't think I could convincingly explain what's happening here, to a > motivated but non-technical friend who wants to understand what they've just > achieved when I've walked them through getting their WebID certificate from > (something like) the social service illustrated in the video. > > People understand what a username & password is (the first is my identity, > the second is a secret that proves I am who I claim), and they understand > what a door-key is (no identity, but I have this physical token which unlocks > a barrier for anyone in possession of the token or a copy). > > The same is not true of a WebID. Making this a one-click operation is nice > (and a Good Thing at some level), but just means that the user knows that it > was _this_ click that caused some black magic to happen, and I'm not sure > that helps. You can prepare the user for what is about to happen, and it is possible to educate users. All this is User Interaction art. > > Therefore... > >>> 2. With firefox, after filling out the form, I get a download dialogue for >>> the cert instead of it installing into the browser. So I saved, then went >>> into preferences and "import" ... which was successful with "Successfully >>> restored your security certificate(s) and private key(s)". Previously, with >>> my-profile.eu, this was automatically installed into the browser (I was >>> using Chrome then). Though I guess it's better to have it export/save by >>> default so you can install the same cert on any number of browsers without >>> hassle. Still, it creates more steps and could be confusing for new users. >> >> In the case of WebID certs downloading the certificate is in fact silly as >> you can produce a different one for each browser. So that message is a little >> misleading. A good UI should warn the user about that. > > Thinking about it, and exploring the behaviours again this week, I'm more and > more sure that the browser is a problematic place to do this work. > _Technically_, it's exactly the right place, of course, and the HTML5 keygen > element is v. clever. But it's killing for users, and coming back to WebIDs > and certificates this week, and parachuting into this discussion here, I've > been a 'user' this week. > > A 'web browser' is a passive thing: it's a window through which you look at > the web. It quickly disappears, for all but the most hesitant and > disoriented users; in particular it's not a thing which takes _actions_, or > where you can store things. That means that the browser creating the > key-pair, and storing the server-generated certificate, is literally > incomprehensible to the majority of anticipated users. > > And even to me. I have an X.509 e-science certificate which needs renewing > every year, and every year I stuff up this renewal in one way or another: the > certificate isn't in the right place, or I try to retrieve the replacement > with a different browser from the one which generated the CSR, or something > else which is sufficiently annoying that I purge the experience from my > memory. And I understand about certificates and the whole PKI thing -- > someone who doesn't is going to find the experience bamboozling, hateful and > stressful. This is work for User Interaction designers. People can do much more complicated things with their computer than what is being asked here. > > It sounds as if Hugh is going to generate his users' certificates off-line > and distribute them; I got a little warm glow when I generated a WebID > certificate (offline) using Keychain Access (KA), and then another using > Nicolas Humfrey's script, and imported it into KA; when the UK e-science CA > (above) started using a downloaded Java webstart application to do the > renewal requests, it was massively easier on my head, even though the > application itself wasn't going to win any design prizes. > > In each case, there was a 'thing' -- a 'certificate' -- which I can see on my > desktop and then store securely in my 'keychain', and I can comprehend that I > should think of it as a 'passport' or 'identity card', since that's a > familiar thing which, like the WebID, is a proof of identity which might give > me access to things on various grounds. > > I'm willing to be persuaded (presuming I'm not on OS X and willing to let KA > look after this) that my browser has a 'keychain' and that I have to put this > passport/id-card in there and leave it there. I'm a bit uncomfortable with > that, since I wouldn't want to leave my passport lying around where I can't > see it, but if you tell me that's safe, I suppose I'll go along with that. > > The crucial thing here is that I can see this 'certificate' file sitting on > my desktop, and I got that because someone gave it to me, or because I > downloaded an application and pressed a button saying 'make me a WebID'. I > then _did something_ with that certificate file, so I have at least some > vague sense that I've _stored_ that certificate somewhere, in a way that is > subsequently proffered by my browser. The web site can show you a public key too shown as a certificate, if that helps. > > I'm happy to have my certificate in a 'keychain', because that sounds like > it's an application which is designed to keep things safe. I think I'd still > be unhappy keeping this 'in' my browser, because that feels like I'm storing > my passport in a pocket attached to the glass of my window, which is > obviously mad. > > I don't have an easy solution to this -- I can see all the problems with > creating applications which users have to run to generate WebIDs, and > regarding which they then have to be given follow-up instructions. But doing > this in the browser, though technically neat and correct, may have killing > UI/model problems, as described above (because of the invisibility and > passivity of the browser in most people's conception), and these problems may > make this the browser-generation route less successful in the end. I am not convinced. The problems with Certificates in the Browser are entirely to do with the problem of dealing with CAs. Clearly a bit of education is needed, and what better than a web site to do that. > > ---- > > Codicil 1: > >>> In general, that brings up some thoughts for me, maybe here's the place to >>> share them. It would be cool in browsers could bake the idea of a WebID >>> into the persona/profile of the browser session. (ie. chromes profiles, and >>> firefox has a profile plugin). Just allowing (by default, i guess) one >>> WebID per persona. This way you are encouraged to manage different profiles >>> at the browser level, rather than juggling a bunch of certificates with >>> naming hacks to figure out which is which... ? >> >> You can contribute your feedback as bug reports to the browsers. >> A place to start is here: >> http://www.w3.org/wiki/Foaf%2Bssl/Clients#Further_User_Interface_Issues > > Oooh, they're awful. I just checked, and I submitted an Apple bug report > about this -- detailing the awfulness and inadequacy of Safari's and Keychain > Access's UIs here -- back in October 2008, which finally received "We are > closing this bug since our engineers are aware of the issue and will continue > to track it" in November 2011, and nothing since. *sigh* The Chrome and Opera UIs are pretty Good. Apple's too, it's just that it has a privacy issue. Firefox and Linux OSes all have a UI problem: they show irrelevant info, but it makes people on those OSes think they understand something deep I suppose. > > Codicil 2: > >> Please let us know if you can think of improvements to the spec text, as we >> will be >> publishing it soon. > > Something I just noticed: In section 2.1.2 of tls-respec.html, the language > feels a little rough. Can I offer: > > ...by using the HTML 5 keygen element. This element can be placed in an > HTML5 form, where it acts as follows: just before it submits the form, the > browser asks the Key Store to create a public and private key pair, and when > it receives the public part of the key from the store, it wraps this in a key > request, as part of the form it sends to the Service. The Service can then > create a WebID Certificate, and return this to the Client to pass back to the > Key Store; the private key never leaves the secure Key Store. This exchange > allows the Server to make the decision about what the Certificate should say, > and what the WebID should be, since it is probably in the best place to do > so. The user experience for this Certificate creation is a one click > operation. Thanks a lot. I adapted the above text, added a diagram illustrating the message flow and posted this here: https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#certificate-creation > > ---- > > I hope all this rambling is useful. > > Best wishes, > > Norman > > > -- > Norman Gray : http://nxg.me.uk > SUPA School of Physics and Astronomy, University of Glasgow, UK > Social Web Architect http://bblfish.net/
