- From: Ben Laurie <benl@google.com>
- Date: Thu, 27 Sep 2012 12:26:12 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-webid@w3.org
On 27 September 2012 12:21, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 9/27/12 3:49 AM, Ben Laurie wrote: >> >> On 26 September 2012 23:43, Kingsley Idehen <kidehen@openlinksw.com> >> wrote: >>> >>> On 9/26/12 5:18 PM, Ben Laurie wrote: >>>> >>>> On 26 September 2012 19:02, Henry Story <henry.story@bblfish.net> wrote: >>>>> >>>>> On 26 Sep 2012, at 19:10, Kingsley Idehen <kidehen@openlinksw.com> >>>>> wrote: >>>>> >>>>>> On 9/26/12 11:48 AM, Ben Laurie wrote: >>>>>>> >>>>>>> No, the point you are missing is that in capabilities the_only_ >>>>>>> authority I need to access a resource is the name of that resource - >>>>>>> the URI in your case. >>>>>> >>>>>> You can seriously believe I am missing that point while also espousing >>>>>> the virtues of hyperlinks as denotation mechanisms for a global web of >>>>>> linked data. That doesn't compute. That's a contradiction. >>>>>> >>>>>>> Security derives from the unforgeability of the >>>>>>> URI, rather than an independent system that decides if some principal >>>>>>> has permission. >>>>>> >>>>>> Security is not derived from the persistence of a URI, its derived >>>>>> from >>>>>> the values exposed directly or indirectly via URI which logic handling >>>>>> routing. I can have many identifiers, but relationship semantics >>>>>> ultimately >>>>>> determine if I can access a resource at an address, directly or >>>>>> indirectly >>>>>> (i.e., name based indirection). >>>>> >>>>> +1 >>>>> >>>>> the idea of an unforgeable URI seems gobbledegook to me, frankly. When >>>>> people spoke of unforgeable things they spoke of things like diamonds >>>>> that >>>>> could not be copied, swords that were made to such perfection that >>>>> never >>>>> could there be two identical versions of them, etc... A URI is by >>>>> definition >>>>> something that can be copied. In fact there is no way of telling of one >>>>> URI >>>>> is an original or another a copy! >>>> >>>> This is true, and is one reason it is hard to simulate capabilities >>>> using >>>> URIs. >>> >>> >>> >>> How do you arrive at these conclusions? If you don't mind, have you taken >>> a >>> look at the Linked Data meme and what its about? How URIs resolve to >>> structured data etc. Basically, you can denote anything entity using a >>> URI. >>> Even better is you take advantage of an HTTP URI since you have the power >>> of >>> indirection in play such that a denotation resolves to representation. A >>> URI >>> becomes an extremely powerful data source name that enables you work >>> wonders >>> with structured data. You can simulate all kinds of capabilities via >>> URIs, >>> the only limits are: >>> >>> 1. our imagination >>> 2. our willingness to look at what Linked Data is really about -- forget >>> any >>> distracting political wars from the past, it's 2012, let start afresh re. >>> AWWW and its capabilities. >> >> Now we're overloading "capabilities" :-) >> >> So, the point is this: object capabilities are a security mechanism, >> like ACLs. Their purpose is to restrict access to resources to only >> the intended accessors. > > > A security mechanism can be an object capability. What do you mean by this? > > >> >> With URIs, there are two obvious ways to implement this: >> >> 1. Make the URIs unguessable - so, I only get access to the resource >> if someone tells me the URI. > > > Yes. Also remember that if privacy is about self-calibration of one's > vulnerabilities then the resource publisher is the URI progenitor. These > days, URI creation, discovery, and propagation will occur via tweets, sms, > blog posts, email etc.. Increasingly, folks with discover URIs > serendipitously. > > >> >> 2. Link the URI to a public key - so, I only get access to the >> resource if I can prove I have the corresponding private key. >> >> The problem with 1 is that the nature of URIs makes it hard to keep >> them secret. > > > They should never be secret. Just like keeping email addresses secret is a > flaw that reflects folks accepting system deficiency etc.. Well, if they are not secret, then you do not get the security benefit and you end up having to use ACLs, which makes you vulnerable to the confused deputy problem. >> People like to send them in emails and IMs and they leak >> quite easily. > > > See comment above. > > >> >> The problem with 2 (which, it should be obvious, fits quite neatly >> with WebIDs) is that it requires changes to clients and servers to do >> the key proof. Or maybe not, actually ... I guess it could be done at >> the back end, wherever you do ACL checks, by instead correlating the >> URI and the key presented in the WebID cert. > > Yes, and that's what those of us showcasing WebID based ACLs are doing. We > are leveraging existing technology supported by browsers, email clients > etc.. You are showcasing ACLs, which, as I have said, have not served us well, and have known problems. >> >> So ... maybe not such a red herring after all. > > > Correct. > > >> >> Not that this fixes any of the problems I've talked about :-) > > > Okay, so lets now hone into your specific problems as they relate to > controlled access to data that's driven by logic, at Web-scale. > > > Kingsley > >> >>> >>> >>>>> The idea of unforgeable URIs, the idea of a web that cannot be linked, >>>>> all of these ideas seem to be like weird beasts from a netherworld that >>>>> nobody has ever heard of, a Medusa that turns all that look at her into >>>>> stone. >>>> >>>> Not that cannot be linked, but that can only be linked by those you >>>> choose to allow to link. The same goal as ACLs, of course. >>>> >>>> But I should not have introduced the idea, it raises as many questions >>>> as it answers. Definitely a red herring. Apologies. >>>> >>>> >>>> >>> >>> -- >>> >>> 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 > > > > >
Received on Thursday, 27 September 2012 11:26:44 UTC