[cap-talk] Process object -> "Subject" - the saga continues

[David Hopwood]

Jed at Webstart wrote:
> There's no doubt that the "object" term encompasses things that have
> methods and therefore engage in computation.  However, it's the very
> generality of the "object" term that so grates for me.  Is there anything
> that the "object" term doesn't encompass (in a computational sense)?

Why is this a problem? Technical terms have to be read in context. It's
silly to insist that they mean *exactly* the same thing in all possible
contexts. Note that it is not being suggested that any use of the term
"object" implies a capability system; only that, *if* we have a capability
system, then "object" has a specific meaning within that system (which is
consistent with its use in OO languages).

> However, when I hear:
> 
> Subject Alice sent a file capability to subject Bob and subject Bob
> invoked it.
> 
> I at least get a bit more specificity.  Then when it comes to more
> nuanced discussions like:
> 
> When communicating a capability should the object have the right
> to specify "do-not-delegate"?  vs.
> 
> When communicating a capability should the subject have the right
> to specify "do-not-delegate"?
> 
> I believe clarity is on the side of the more specific term, "subject".

It doesn't much matter, because in a cap system there are not distinct
sets of subjects and objects; they are always unified.

> The "object" term to me can be confused with the resource that
> the capability provides authority (permission?) to access.

In this case, if you're talking about sending a message, then the more
specific term for what you want is "sender". The sender is of course
an object, as well as a subject.

> Shap wrote:
> 
>  >1. Unfortunately, the term "subject" was used incorrectly in some of the
>  >very early literature to mean "principal". Whether this is correct or
>  >not is a matter of definition in any given paper, but it is a common
>  >misunderstanding of the term even in expert discussions.
> 
> I would like to get some references on this.  Are you referring to 
> literature
> that is from the "process" time period?   We chose to ignore/overwrite
> that "process" term with a new and more ambiguous "object" term,

"process" is itself heavily overloaded.

> why not reclaim a more specific term like "subject" from any association
> with a "principle"?

"principal".

> When you say "principle" above I assume you are
> referring to a person vs. some sort of computational "principle"?

In cryptographic usage, a principal is an entity defined by knowledge
of some secret. This may be a process, a person, or an organisation for
example. I prefer not to use this term at all in cap systems, but if it
is used, it should be consistent with the cryptographic meaning, since
that is now the most common technical usage.

>> >3. In access control modeling, it proves that there is absolutely no
>> >difference for formal analysis purposes between subjects and objects.
> 
> I guess I again need a reference and perhaps some clarification.  If
> by the above you (Shap) mean that all subjects are objects - well
> of course I accept that.  That's exactly the problem.  The "object"
> term is so general that it has no meaning when used to convey
> the actor that does the work in a computational transaction, specifically
> as distinguished from the actual "object"s of their work.  However,
> if you mean something stronger than that as seems to be implied
> by your "absolutely no difference ... between subjects and objects"
> then I would like to hear more about it.  Do you mean that all
> objects are also subjects?  For example a "file" object is also a
> subject?  If so in what sense?

In the sense that it behaves exactly like a subject for all purposes.
It may be implemented just like any other subject, or it may be implemented
by code built into the capability system, but that's mostly irrelevant
(and what looks like a built-in file may in fact be a wrapper object that
is not built-in).

This argument is a bit more stretched for stateless objects, but anyway
there is no need to have use two separate terms "subject" and "object"
in capability systems; one will suffice.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>