[cap-talk] Persistence as a cap value (was: Re: ...PLASH discussion)
Rob Meijer
capibara at xs4all.nl
Wed Mar 12 07:19:05 EDT 2008
On Wed, March 12, 2008 07:27, Jed Donnelley wrote:
> For me the most natural form of access delegation
> is via a reference in a message. Is that because I
> think like a program ;-) ? I don't think so, but
> then perhaps I'm not the best judge. I believe that
> such a delegation mechanism is just the most parsimonious
> and "natural". I say exactly what I'm delegating (access
> to whatever the reference refers to) and "who" I'm
> delegating it to - the receiver of the message. Sort
> of like sending a physical key in a postal letter.
I completely agree with this part.
> In some sense the receiver of any message is always
> a program, but I may know that by doing a delegation
> by a program acting on my behalf (the sender) to a
> particular receiver that the net effect is a delegation
> of access to some person. A persistent delegation of
> such an access. To me sending an email that includes
> a 'capability' (e.g. a Webkey) is a very natural form
> of delegation, which is in turn what seems to me to
> be a very simple and easily understood for of access
> control "management" - at least for the initial
> delegation, revocation or after the fact (of
> delegation) management is another issue (e.g. a
> Horton UI).
The main issue here is I think that delegation can
only be natually persistent if 'all' concerned objects are
naturally persistent.
If a system reboots, the people involved remain persistent,
the program code remains persistent, but the programs involved
are new instances of this code, possibly started with different parameters
and/or run in an other context. The notion of a process being an
incarnation of a 'persistent' program is therefore unnatural, and thus I
feel persistent delegation is not directly suitable.
As I am trying to do in my MinorFs project, I do however feel that a
(pseudo) persistent process concept would allow the processes to act as
naturally persistent objects, thus enabling persistent delegation.
Without such a construct I feel persistent delegation with intervention of
non persistent processes seems to be pushing to much dangerous powers to
the people using the system, what IMO could very easily be bad for POLA.
So my (initial) stand on this topic would currently be 'dont try to do
persistent delegation with non persistent processes'.
I am very interested to hear alternative views on this.
Rob
More information about the cap-talk
mailing list