This is great! Thanks guys. I normally really, really don't care about all that crypto stuff (it should all happen transparently), but I'm find all this interesting!
So yes, I created a p12 (using http://id.myopenlink.net/certgen/ - you sometimes have to trust someone :-) ) and emailed. I am confident (!) that with Keychain things will be fine, but less sure about Windows. Opened it on a Windows box, and it seems to have taken the thing to heart and put it in some certificate management thing. I am a little uncertain what I should put at the URL (non-FOAF) I gave it - the final page gave me some options with micro data, RDFa etc - I am guessing I can just wrap any of them in <html><body> etc? Anyway, I can sort that. So now all (!!!) I really need to do is make my wordpress site look for the ID thing. Hmmm. Melvin, did you get any response to http://lists.w3.org/Archives/Public/public-webid/2012Aug/0041.html ? Or Kinglsey, what did you do on the server side of your photo? Cheers On 9 Aug 2013, at 13:25, Kingsley Idehen <kide...@openlinksw.com> wrote: > On 8/9/13 7:47 AM, Norman Gray 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. >> >> 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 >> >> > +1 > > In addition to the above, note that IE doesn't support <keygen/>. We had to > make a .NET equivalent of a signed applet to create what (on the surface) > looks like the normal <keygen/> flow. > > Having played around with many workflow scenarios over the years, we > concluded that <keygen/> should simply be an option, but not the default. > > Hugh introduced a use-case that does actually reflect how many will be > introduced to this concept i.e., the most tech savvy person in the friend > network will generate WebID bearing certificates offline, and then distribute > to other friends. The same thing will happen amongst family members -- > something I've already experienced personally -- where the following > workflow steps provided a solution: > > 1. I took a photo of the kids > 2. I notified some family members about the photos -- via an email that > includes pkcs#12 file attachments or download URLs > 3. I let them know that seeing the photos requires clicking on the pkcs#12 > file -- so that they can use it as proof of identity when viewing the shared > photos > 4. I shared the pkcs#12 password with them (phone, sms, separate email etc..) > 5. done. > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > >
