Christian Theune wrote:

Am Freitag, den 16.12.2005, 07:49 -0500 schrieb Jim Fulton:

Christian Theune wrote:

I think if we can guarantee never to reuse a user id, provide a tool for
doing RIP and we do not provide undo we are fine.

Only if we manage the user ids.  We often get principal ids from outside
sources.  In fact, we usually do this in production.  In the case when
we're using an external principal soure, we also don't autmatically
know when the principal is removed.

Also, current principal-management facilities in Zope 3 allow managers to
pick ids.  We probably would need to curtail this or at least prevent

It's probably not wise to rely on this.

That sounds like for a usable certified system RIP might be out of
scope? Hmm. Hope not.

There could be a UI for removing principal grants that a manager
could use to remove grants after a principal has been removed

Right. The security policy is part of the authorization system.
The authorization system, or at least a CC-complient authorization
system should probably grow a principal-removal API.

Well. If that would be an authorization system that would not be helpful
in everyday business, then growing one only for CC would be beside the
point of the certification to assure people that the system they use on
a daily basis matches their security expectations.

I'm not conviced that this is an every-day requirement.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to