W3C home > Mailing lists > Public > public-webid@w3.org > September 2012

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

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Thu, 27 Sep 2012 09:56:09 +0200
Message-ID: <CAKaEYhLhOL+-JOOWR6+0sAJMVa3-=RMPnxZx0RGXs_smy-33Yg@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, Henry Story <henry.story@bblfish.net>, "public-webid@w3.org" <public-webid@w3.org>, Andrei Sambra <andrei@fcns.eu>
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.

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


>
> >
> >
> >
> >>
> >>> 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 07:56:38 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:40:59 UTC