- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 9 Aug 2013 16:35:43 +0200
- To: Hugh Glaser <hg@ecs.soton.ac.uk>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, Norman Gray <norman@astro.gla.ac.uk>, "<public-lod@w3.org>" <public-lod@w3.org>
- Message-ID: <CAKaEYh+BQJ-+U-P_rnp0-R84Gquz9ad4oWPiudaZ5wAZ=8upww@mail.gmail.com>
On 9 August 2013 15:51, Hugh Glaser <hg@ecs.soton.ac.uk> wrote: > 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? > I didnt get any feedback on wordpress. However, Stéphane has written a great mod for drupal: http://drupal.org/project/webid Since it's also PHP, I suspect it would not be too hard to repackage as a wordpress plugin ... > Cheers > > On 9 Aug 2013, at 13:25, Kingsley Idehen <kidehen@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 <nick@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 > > > > > > > > > > > > >
Received on Friday, 9 August 2013 14:36:11 UTC