Questions
- Do we need to explicitly model the distinction between users and other Persons described or referenced?
We know we will have roles associated to 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? Both will need associations, possible contact info, etc. We might have policies around minimal info for users, but not for referenced Persons. 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.