On 8/7/13 6:12 PM, Hugh Glaser wrote:
Norman, thanks for being so attentive to my needs :-)I actually started looking at WebID just because of RWW.IO But in answer to your footnote: It turns out last week I brought up a private social network, using Wordpress, for a group of people, who aren't just n-t-f (I finally guessed this was non-technical friends, I think :-)), but actually pretty much t-i-f (technically illiterate friends) - some don't have their own email accounts and also some of them clearly have problems with the htaccess dialogue in their browsers, and certainly can't seem to find the "more" button at the bottom of a page! At the moment, I have a single username/password (u/p) that we all know for access to the site, using htaccess (they don't need to know it is htaccess, Kinglsey, they just see a request for a u/p). If they want to contribute, then they have to login, using a different u/p I have made for them (actually the same password!)(*) (I decided, probably in my ignorance, that adding htaccess was better than trying to understand how to keep the entire site blocked using Wordpress - I don't even want it to be known about.) The site also has personal profile pages, so that people know each others' addresses etc - hence the wish to block the complete site. There are wordpress plugins etc that sort of would help, but not quite. Anyway, I thought I would ponder on how WebID might help to do some or all the personal stuff associated with the site, and whether there would then be extra benefit for the users and/or me. I know that these people, as many are, would be very wary of giving any information to a web site they didn't trust, which is probably anything other than my site, gov.uk, bbc and a few others. It isn't all clear to me - hence the probable lack of focus of my comments. But it is a real use case that I am using, so I sort of find it interesting.
Okay, imagine this flow: 1. you generate WebID bearing certificates and private keys for your friends 2. package as pkcs#12 files 3. dispatch via email4. exchange the password for opening the file by phone (since encrypted email isn't an option, just yet for this friend profile) 5. use a WebID+TLS based ACL to protect the WordPress endpoints (I am assuming that you self host your WordPress instance)
6. share new URLs for WordPress service with friends. 1-6 only requires the following actions on the part of your friends: 1. read email 2. open the attachment3. follow native OS instructions for processing pkcs#12 files (i.e., storing to native OS key store)
4. done.Next time they visit the URL for your WordPress service, they are challenged to present their digital certificate (or identity card) which will be presented automatically by their browser. They click OK, and they should okay :-)
Yes, you read that right - I am talking about people who don't have email accounts (and don't want one), but might use WebID to access sites!
Huh?Okay, so scrap the email exchange part. You can place the pkcs#12 file at a public or private network location. Use the phone to exchange passwords for opening up the file when prompted by their host OS.
And no, they have never used a program that can do text editing, not even Word.
I wasn't expecting them to edit Turtle, so in this case, they should be set. It's all in the pkcs#12 file .
I hope that gives a bit more context.
For me, yes ! Kingsley
And thanks again for all the interesting discussion - it's great to see the list working so well. Hugh PS (*) I realise that some people will find the security level appalling - but security is always a balance of convenience against security, and I have gone for quite weak security with more convenience. I may change this, and in fact that is part of my interest in WebID. On 7 Aug 2013, at 21:36, Norman Gray <[email protected]> wrote:Greetings. Thanks, Kingsley, for the trace of the various steps. On 2013 Aug 7, at 19:14, Norman Gray <[email protected]> wrote:Hey -- this stuff is easy! (and nearly works)Walking home, it occurred to me that this is easy in a very _specific_ sense: (given that someone had added some UI chrome around Nicholas Humfrey's script) I would not think it unreasonable to walk a non-technical friend through that process, giving them the script but not touching their mouse or keyboard, and ending up with a usable WebID. Now, that particular process requires that we first sign said n-t-f up at purl.org, on the entirely reasonable assumption that they don't have an account there already. That violates Hugh's demand that he avoid 'one last login'. However it nonetheless does distil out the point that this last step, of associating a 303-redirect with a URI you control, is the _only_ irreducibly exotic web step in the process. Also, purl.org shows that that can be done straightforwardly (or reasonably so, since purl.org's interface could use some prettification). Hmm: things like bit.ly are URI rewriting services, albeit 302-only. People manage to use bit.ly aaaall the time. Therefore _if_ Hugh discovered that any of the accounts he already owns allows him to add this one bit of plumbing, and presuming he has something like Dropbox, to turn the action of putting bytes on the web into a non-exotic step, then he's sorted. By the way: 'non-exotic' here, means an action that the n-t-f already has some mental model of, and which they have already managed to do, for some other entirely pragmatic reason. Interestingly, I suspect that the process of generating the WebID certificate in the browser fails this test, _even though_ the certificate has to end up in the browser (other than on OS X), because there's no clear mental model of what's happening in this step, and that matters. ---- The above does sidestep the question of why the n-t-f so wants a WebID. None of the examples that have appeared in this thread so far are compelling in the right way, I think, but it would only take one gmail or dropbox or similar to decide to try WebID, for the whole thing to suddenly work. All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK
-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
