<Hugh comes back to play /> Thanks Kingsley, and Melvin and Henry and Norman. So, trying to cut it down to the minimum. (Sorry, I find some/many of the pages about it really hard going.) If I have a photo on a server, http://example.org/photos/me.jpg, and a WebID at http://example.org/id/you What files do I need on the server so that http://example.org/id/you#me (and no-one else) can access http://example.org/photos/me.jpg? I think that is a sensible question (hopefully!) Cheers Hugh
On 9 Aug 2013, at 16:30, Kingsley Idehen <kide...@openlinksw.com> wrote: > On 8/9/13 11:09 AM, Hugh Glaser wrote: >> Thanks Kingsley, >> On 9 Aug 2013, at 15:09, Kingsley Idehen <kide...@openlinksw.com> >> 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? > > Okay, to be clearer, there are two things in play re. authentication via > WebID+TLS: > > 1. basic identity verification -- this is the relation lookup against your > profile document (this is the minimal that must be implemented by a WebID+TLS > server) > 2. ACLs and Data Access Policies -- this is where, in addition to #1, you set > rules such as: only allow identities that are members of a group or known > (i.e., via foaf:knows relation) by some other identity etc.. > > So starting simple, your first step would be #1. > >> What plugin in wordpress do you mean? > > I thought there was a WebID plugin for WordPress. Thus, post-installation, > you would be able to achieve step #1 i.e., the plugin turns your WordPress > installation into a WebID+TLS compliant server. > >> 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. > > Also note, if you are hosting WordPress you can make the plugin yourself. It > boils down to a SPARQL ASK on the relation that associates a WebID with a > Public Key. > >> >> 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. > > Yes, that threw me off too. >> >> 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. > > I really assumed that circa. 2013 an interested party would have build a > WebID+TLS server side plugin for WordPress. > > Ah! Just realized something, there's an OpenID plugin for WordPress [1], > which means you can (if you choose) leverage an OpenID+WebID bridge service > [2]. > > > Links: > > 1. http://wordpress.org/plugins/openid/ -- the OpenID plugin for Wordpress > (this gives you the authentication functionality for your WordPress instance) > 2. http://bit.ly/OcbR8w -- G+ note I posted about the OpenID+WebID proxy > service (which you can leverage in this scenario too!). > > Kingsley > >> >> 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 <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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> >>> 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 > > > > >
