Re: automatic policy embodiment and enforcement

On Mon, 2004-09-20 at 17:54, David Hopwood wrote:
> In a typical ACL system, principals do not *really* represent users; they
> represent "any process that might be run by such-and-such user". The concept
> of "principal" in a cap system is not lower level; it just corresponds more
> realistically to the entities that it is possible and desirable to associate
> permissions with (some of which are *trusted agents* of users).

I think there is a more precise way to formulate David's statement:

In real ACL systems, subjects are not persistently named, so principals
are substituted. For purposes of understanding ACL protections, a
"principal" should be understood to mean "the equivalence class of
subjects that are (transitively) run under a given authentication
identifier."  That is, the terminology of ACL systems is mildly
confused. We would like "principal" to equate to "authentication
identifier", but the way it is applied in a typical ACL system does not
equate to this.

Actually, in real ACL systems the equivalence class is potentially much
broader than this, because an ACL can refer to groups, so the
"principal" in an ACL system is actually "the equivalence class of
subjects that are (transitively) run under any authentication identifier
that is a member of some designated group identifier". In this
definition we should understand "users" to be modeled as singleton
groups.

Note that any time you say "I am designing a system that predicates
authorization decisions by taking an equivalence class of subjects", you
are necessarily creating a system that cannot make authorization
decisions on an individual subject basis. This is true precisely because
subjects in non-persistent systems do not have durable identities.

Note: by 'real ACL systems', I mean the ones that we actually see in the
world, not to be confused with the usual formal definition of an ACL...