On 9 Aug 2013, at 17:09, Hugh Glaser <[email protected]> wrote: > Thanks Kingsley, > On 9 Aug 2013, at 15:09, Kingsley Idehen <[email protected]> > wrote: > >> On 8/9/13 9:51 AM, Hugh Glaser wrote: >>> 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? >> >> In my case, I Just made an ACL based on a combination of the identity claims >> that I know are mirrored in the WebID bearing certificate. In the most basic >> sense, you can simply start with the basic WebID+TLS test which is part of >> the basic server side implementation. Thus, I would expect the WordPress >> plugin to perform aforementioned test. > Sorry mate, I have little or know idea what you are talking about. > What would an ACL look like?
Look at the code at: https://github.com/stample/rww-play It shows how you can use curl the unix command line tool to 1. create a document 2. edit the acl with PATCH to make it world readable 3. edit the document with PATCH all this using an initial implementation of LDP+WebID+WebAccessControl you'll find links from the github README > What plugin in wordpress do you mean? > It is probably the case that this is now too much detail for the list (I > think that the whole discussion has been great for uptake of WebID, which is > relevant to Linked Data). > And it is probably the case that I am just too ignorant of the whole thing to > attempt to do the server side of ti, especially when it is not a raw site, > but Wordpress. > And people have been too polite to tell me. > > Thanks for your response Melvin; I guess I got a bit mislead (or hopeful!) > because Angelo's wp-linked-data plugin has webid as a keyword. > > I think I will now consider myself Retired Hurt > (http://en.wikipedia.org/wiki/Retired_hurt_(cricket)#Retired_hurt_.28or_not_out.29 > )! > I hope to return before the end of the innings. > > Best > Hugh >> >> BTW -- When you distribute pkcs#12 files, the receiving parties don't >> actually need to have any knowledge of the actual ACL that you use to >> protect the resources being shared :-) >> >> Kingsley >>> >>> Cheers >>> >>> On 9 Aug 2013, at 13:25, Kingsley Idehen <[email protected]> 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 <[email protected]> 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 >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> -- >> >> 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 >> >> >> >> >> > > Social Web Architect http://bblfish.net/
