- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 27 Sep 2012 07:21:10 -0400
- To: public-webid@w3.org, "benl@google.com >> Ben Laurie" <benl@google.com>
- Message-ID: <506436A6.2000000@openlinksw.com>
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. > > 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.. > 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.. > > 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 27 September 2012 11:21:37 UTC