[E-Lang] Authority -- what is its dual?

[Marc Stiegler]

> It seems that my different definition of authority has come from
> reading Marc Stiegler's `E in a Walnut'.  It says ``Only immutables
> that encapsulate no authority actually move across computational
> boundaries'' in the context of what gets passed by copy and by
> reference for remote method calls; I take this to imply that
> immutables don't convey authority.  It says ``...it only imports those
> parts of the Java API that have been audited for capability security
> and found to convey no authority'' when talking about `import:',
> referring to APIs like java.lang.Math, and it then says explicitly
> that ``the Vector class conveys no authority''.
>
> Do you regard immutable values (as well as read-only values that might
> be modified by someone else with write access) as carrying authority?
> What do you consider to be an operation? -- are operations required to
> change or detect state?

I am mainly the chronicler of capability thinking, not one of the deep
thinkers myself, but I will offer the following observations that I believe
the deep thinkers will agree with:

-- Immutable objects do not carry authority. However, access to immutables
may be authorities. For example, access to the immutable picture of the spy
we have in bin Laden's inner circle is a powerful authority, not one to be
handed out lightly :-)

--  The Vector class does not convey authority. There can be, however,
classes for which access to the class is an authority even though the class
itself is pure computation, akin to the immutable photo above. My example is
the Perfect Stock Predictor program, which, when fed the state of the stock
market for the last month, perfectly predicts the state of the stock market
a month from now. The people who create the Perfect Stock Predictor program
would consider it a tragic loss if authority to access it were conveyed to
outsiders, since the Perfect Stock Predictor can only predict stock in the
absence of a second Perfect Stock Predictor user :-)

-- A very interesting and difficult example to think about--a good
challenge, if you will--is to think about the uri string that represents a
capability ("cap:" followed by machine address followed by vatid followed by
objectid). This is an immutable string that seems to pack a terrific
punch--get your hands on it and powee!--you're in! Markm would tell me
incessantly that the uri string did not convey authority, and I would mumble
a silent disagreement and go back to work. I only recently have started to
appreciate the difference, in the context of the uri string, the difference
between having access to the string and having the capability.

Once you have the uri string, you can't really reach the capability: you
need an introducer to convert the string into a capability. This is
analogous in E to having the string which is the path to a file (which for
many interesting files is easily guessed), but does you no good unless you
also have access to the file__uriGetter ("<file: .... >") which is needed to
convert the string into a file handle/capability.

I was confused about uri strings because, for the first couple of years of
working with E, I only worked with distributed systems in which the mutually
suspicious parties were on different machines. If you are running on another
machine and you get somebody else's uri string, you are indeed a trivial
distance away from the capability, since you have your own introducer
sitting there waiting to serve you. The distinction only becomes clear in
the case of mutually suspicious objects on a single machine (when running
caplets, which is what I'm doing these days). You can hand a caplet all the
uri strings for all the resources on your computer, but they are useless to
the caplet without an introducer--and caplets just don't ever get direct
access to the introducer.

However, though the uris themselves are not authorities, access to them is
indeed an authority, just as access to the photo or the stock program is an
authority. If a caplet gets access to both a uri string and access to
another computer, then the caplet can transmit the uri string to a remote
location that has another introducer with which to create the actual
capability.

I don't know if this helps or if it hurts, but it is probably useful to
think about :-)

--marcs