Page Comparison

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.
  
  

  Panel
  title Resolution
  [PatrickS]:

  Person only models actors in the system. If we do not need to authenticate them, nor track contributions, nor maintain contact information for them, then they probably need not be modeled as a Person in this service

  since people can move between the groups and other roles, we will unify the models.

• 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.
  
  

  Panel
  title Resolution
  [PatrickS]:

  We will liley need to support hybrid authentication systems. The Person service may define the authentication model used to map to a Principle. In general, roles and policies are enforced using Princples, although they will often be defined (in a UI) using Person or Organization names

  Authentication, Authorization and Account services are modeled separately. See those services for a discussion of these issues.

• Will we define roles only relative to a Person (Principle), or in some cases relative to an affiliation, so that, e.g., we allow certain permissions to inhere to the curator of another collection? This is not a question about groups and organization, which is separate. It is a question about a logical role association that is defined not relative to a Person but to a position held at an institution (Organization). This may be too complex to bother with, but it would be interesting to know how the functional team feels.

  Panel
  title Resolution
  [PatrickS]: Authentication, Authorization and Account services are modeled separately. See those services for a discussion of these issues.