Shibboleth Developers

[Parviz Dousti <>]

Here is the way I see it:

In general and for most cases the two level model (user and Admin) would 
work fine. But there would be cases that a group of users might want to 
delegate the task of managing their ARP ( a resource branch of it) to 
someone.  Also I can see that Admin might want to delegate the management 
of some ARP:Resource objects in to someone else.

Here is how I propose we do it:
 - I am going to assume for now that we only have "insert" access right. 
Of course it can be easily expanded to other rights.

 - Given the ARP model we talked about 
(http://icap.andrew.cmu.edu/aa/AA.htm) each of the following objects would 
have an ACL.
        - ARP object.
        - ARP:SHAR object.
        - ARP: RESOURCE object.

 - Think of ACL as a set of uids.  Users who are in the ACL of and object 
can "insert" an object hanging off of that object.  e.g. if user foo is in 
the ACL of SHAR object of my ARP,  foo can create a new RESOURCE object for 
me.

 - Basically that is all!  Once we expand the rights to read, write, 
browse, and admin(change ACL), etc. we can control it all.

 - Notice that ARP:ATTR does not have an ACL as I see the filter as an 
integral part ARP:ATTR object.

What do you think?

Parviz


------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--