[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Internet Capability Service - wideword.net,
From:       Jed at Webstart <donnelley1 () webstart ! com>
Date:       2005-11-30 21:50:37
Message-ID: 6.2.5.6.0.20051130103857.046828a0 () nersc ! gov
[Download RAW message or body]

At 04:45 PM 11/29/2005, Pelle Braendgaard wrote:
>I think I understand the read only part now. You would like a possible
>read only url, without sending the email.

Exactly, since sending the read-only URL via clear text email exposes
it to snooping.

>I am thinking of some method of giving it a nick name and popping up a
>window with a new URL so the original RW url doesn't disappear. This
>would allow you to copy and paste the url into an email or chat
>session.

That would be fine, since I could then encrypt my email or chat.
I could of course always store it in a file as well if I so chose,
even another one or your files accessed through another URL/capability.

>I am also thinking of adding an optional password ...

I'm not sure I understand what you mean when you say an "optional
password".  Do you mean that a password would be required to access
the resource in addition to the URL with the Swiss number?  I
personally don't like that idea.  How then would the password be
communicated?  However, as long as it's optional I guess I can't complain,
unless somebody gives me such a capability.  This seems to me to be
one of those situations where somebody may think that they are adding
security, but in fact they are adding complexity, overhead, barriers, and
confusion and consequently reducing actual security.

>and a way of generating a new cap, the way you might change a password
>in a normal system.

A new capability to the same resource?  That effectively invalidates
(revokes) the old capability if I'm understanding you correctly?  Would
that operation also invalidate any outstanding read-only derivative
capabilities?  Would such an operation be available on the derivative
read-only capabilities?  If so, what would it do?

May I suggest a design criteria?  I'll mention it in any case to solicit
comments from others.

What I suggest is to imagine using the "password change" service
that you want to support in the role of a proxy service.  That is, I
suggest imagining any subject (person, process, active object)
that has one of your capabilities that might find itself in the position
of wanting to share it, BUT also wanting the ability to revoke that
sharing at a future time.  I believe this simple requirement creates
the need to support a hierarchy (tree) of capabilities nominally pointing
to the same resource (e.g. the file).  That is, say I have a RW capability
to a file and I want to share it with you but retain the ability to revoke
it at a later time.  You then get that capability and want to give a
copy to an application that you have limited trust in with the ability
to revoke the capability after the application terminates.  You should
have the ability to revoke the derivative instance of the capability that
you gave to the application and still keep your primary instance, e.g.
for use with another application.  I might also choose to share another
derivative instance of my capability with somebody else or with some
application that I have limited trust in.

Everything said about RW capabilities applies to derivative RO capabilities.
That is, if I revoke a RO capability, all its derivative RO capabilities
are invalidated.  If I revoke a RW capability all its derivative capabilities,
RW or RO are invalidated.

The remaining question it seems to me is to determine what authority
is required to revoke a capability and how to specify capabilities to be
revoked.

What I suggest (from some limited past experience) is having access
to any capability provide the authority to revoke any subsidiary
capability, considering RO capabilities "subsidiary" to RW capabilities.
As a somewhat special case it seems reasonable to me to have
possession of a RW capability grant the authority to revoke (reissue)
the owned RW capability itself (most like your "change password"
function).

I'll be interested to see if I get any reactions on the above.

Beyond the above, however, I think the most important facility
that you can provide Pelle is the ability to upload files into
file resources and have them serviced through your URLs with
their intrinsic type.  Namely, I can upload files of type jpg, html, doc,
mpg, txt, etc. and they can be retrieved through a URL with their
typed extension.

In any case, good luck with your service!  Do you imagine commercializing
it?

--Jed http://www.webstart.com/jed/ 

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]