Re: WebID questions -- was: [dane] Call for Adoption: "Using Secure DNS to Associate Certificates with Domain Names For S/MIME"

On 27 September 2012 08:56, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
> On 27 September 2012 09:49, Ben Laurie <benl@google.com> 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.
>>
>> 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.
>>
>> 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. People like to send them in emails and IMs and they leak
>> quite easily.
>>
>> 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.
>>
>> So ... maybe not such a red herring after all.
>>
>> Not that this fixes any of the problems I've talked about :-)
>
>
> Spot on.
>
> I think Tim's intention with ACLs is to bring an analogy, of the UNIX file
> system, to the Web.

My point is that ACLs don't work well for us in UNIX and there's
really no reason to suppose they will work any better on the Web.

> In a sense, PKI is only one class of solution to this kind of authentication
> and authorization.  A cookie, for example, could work too.

Capabilities don't really have anything to do with PKI - at least, not
the I part. There is no need for infrastructure - in fact, it is
likely to reduce effectiveness.

A cookie actually is a capability, at least as often used - i.e. an
unguessable string that gives the holder access to certain resources.

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

Received on Thursday, 27 September 2012 08:16:24 UTC