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. 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. 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. 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. ---- 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* 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. ---- 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
