Re: Simple WebID, WebID+TLS Protocol, and ACL Dogfood Demo

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