Questions
Note that it is better to place discussion points inline, as sub-bullets, than to put them in comments where the context and flow is harder to reconstruct.
- Do we need to explicitly model the distinction between system users and "referenced Persons"?
We know we will have roles associated to system users for various AuthZ issues. However, is it enough to just note Persons with user AuthZ role associations, or do we have a fundamental modeling difference between these system users and other Persons described or referenced? We might have policies around minimal info for users, but not for referenced Persons. Both will need associations, possible contact info, etc.
Some of the uses for referenced Persons include authors of documents, staff at other institutions (responsible for loans, exhibitions, etc., but not users of the local system), faculty, etc. Note also that not all "users" in the system are necessarily users of the primary CollectionSpace services. E.g., there may be public users of a derivative website that presents a collections browser, an online exhibition or a tagging tool. These public users may register to preserve state like tags, favorites, etc., but may never be granted access to CMS tools. At the core, we will likely have a generic Person entity service, and could then specialize this to define/enforce policies on information requirements. The key here is to specify when a role is not enough, so we do not conflate specialized person entities with roles. If we can, we should probably stick with Person and not define subclassed entities. OTOH, how does this align to KSS and their Student entity model? Is Student a Person subclass, or a Person-Role association? Note also that KSS handles this with a mechanism of Type values for a variety of entities, including Resource, Person, Organization, etc.
- We need to be able to model a range of different populations. These include museum staff, researchers from other institutions, and public annotators (to track tagging activity). This in turn may place serious demands on the authentication and authorization services, since local institutional Auth/AZ systems may only support employees (e.g., integrated SSO and LDAP systems).
Will we need to have classes of Person that can be associated to different Auth/AZ systems? This kind of puts the AZ cart before the horse (defining some roles in the Person service), but it may be necessary. Or perhaps we will need to have some AZ support for Auth models. We basically need a federated Auth system that can work with unified Person and AZ services.