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

On 9 August 2013 18:22, Hugh Glaser <hg@ecs.soton.ac.uk> wrote:

> <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!)
>

[
  acl:accessTo <http://example.org/photos/me.jpg>;
  acl:mode acl:Read, acl:Write;
  acl:agent <http://example.org/id/you#me>
]




> Cheers
> Hugh
>
> On 9 Aug 2013, at 16:30, Kingsley Idehen <kidehen@openlinksw.com>
>  wrote:
>
> > On 8/9/13 11:09 AM, Hugh Glaser wrote:
> >> Thanks Kingsley,
> >> On 9 Aug 2013, at 15:09, Kingsley Idehen <kidehen@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 <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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> --
> >>>
> >>> 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
> >
> >
> >
> >
> >
>
>
>