[Zope3-dev] Re: principals vs. users

[Jeremy Hylton]

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

  GvR> [jim]
  >> Given that several principals can be associated with a single
  >> human, it might be confusing to talk about them as separate
  >> users.

  GvR> Unix says username to disambiguate these, when that's
  GvR> necessary.

What does "these" refer to?

I've lost the context of Jim's message but I agree that it would be
confusing to talk about a set of principals as separate users.  One of
the points of talking about a principal is to avoid all the confusion
that occurs when you talk about users.

  >> It *might* be useful to actually have a concept labeled "user"
  >> that is a (possibl implicit) "group" of all of the principals
  >> associated with a particulat human.

  GvR> I've never heard of that, and I don't know how you would prove
  GvR> that those principals really are the same person.  Anyway, if
  GvR> you want that concept, call it "person".

I agree.

Jim and I talked a few days ago about compound principals which may be
what motivates his comment.  A compound principal is one of the form
"SSL connection as Guido" where the SSL connection is the principal on
the local machine that speaks for Guido.  It is typical to check that
the SSL connection actually speaks for Guido and then just reason
about Guido.  

But there may be circumstances where you want to associated
permissions with the compound principal itself.  For example, to
distinguish between Guido logged in using http and Guido logged in
using https.  (Amazon.com does something like this.)

  GvR> [me]
  >> > And another thing that came to me while writing that reply: in
  >> > terms of the principal <--> permission mapping, groups and
  >> > roles really are equivalent: both define a set of (principal,
  >> > permission) pairs that's the intersection of some rows and some
  >> > columns.  Where is my thinking wrong?  What is in your opinion
  >> > the difference between these two?
  >>
  >> I agree that, currently, roles and groups are operationally the
  >> same, however the intent is very different. A "role" is a
  >> responsability of a principal in some place.  A group is a
  >> principal that is an assembly of other principals.

  GvR> Yes, Philip's post clarified to me the psychological difference
  GvR> between groups and roles; I now agree it's important.

All the more reason to get some good definitions and examples into the
proposal!

  >> - In the future, principals will be able to control what roles
  >> they can have at a point in time. They will be able to enable and
  >> disable roles much as they would put on and take off hats.

  GvR> Cool.  Like Unix 'newgrp' but better. :-)

I think this is the way in which "role" is more typically used.

  >> It may turn out that people only have one role (wear one hat) at
  >> a time.

  GvR> Unix has one primary group but any number of extra groups.  I
  GvR> don't know if this translates to Zope thoug.

Now you're mixing role and group again :-).

I think groups are an abstraction that helps manage assignment of
roles.  You and I are in the PythonLabs group and everyone in the
PythonLabs group has the administrator role for Python CVS.

  >> o Risks of client-side trojan attacks will be partly mitigated.

  GvR> How?

If you log in using your "sys admin" role, you may not have permission
to edit documents that requires your "editor" role.  And vice versa.
It limits your vulnerability to a single role's permissions rather
than all of them.

Jeremy