Goals
Short Description
COmanage supports three types of administrator users. The Platform, CO and COU admin. The first one has global access permissions. The CO admin has CO level access permissions, which stands for View and Manage both Population and Configuration data in a CO. Finally, the COU admin has:
- CO level access permissions for the View action of Population data
- View and Modify access for all COU Populations
- No access to any action for CO configurations
An immediate deduction of point one(1) is that COU admins have read and/or write access to information, CO People personal data, that is beyond their privileges. This access does not only cause administrative issues, but also legal issues for organizations subject to GDPR regulations.
We propose the definition of a visibility system handled by the COPerson itself, user-driven consent ("I authorize my attributes to be released in optional contexts"). This means that the COPerson will be able to define who is eligible to access his personal data and who will not. In more detail, we propose a three level visibility system as outlined below. (Default behavior should be enhanced privacy.):
- CO, the entire CO has access to the CO Person’s profile
- COU, all the members of the COU have access to COU members profiles
- CO Person, the profile is private and no one has access except from the owner
The system can become much more flexible if we apply the visibility system for each section of the CO Person’s profile. For example, a CO Person could provide CO level visibility for the entire profile, but only COU level visibility for the email address, ssh keys, etc
In advance, we propose the recalculation of COU Admin permissions in such a way that they can View and Manage only their own COU population. In other words, a VO implementing business process driven authz ("COU Admins can always see their own population, but never any other COU's population").
Moreover, related to point three(3), we are strongly in favor of assigning more administrative tasks to COU admins relevant to actions derived from their granted permissions. For example, create sub-COUs, Enrollment Flows, e.t.c.
From a technical point of view, this in short implies:
- Modify the left side Menu under People drop down list
- My Population should be an aggregate of CO People in all COUs the user is an admin or could be omitted.
- Organization Identities should be an aggregate of the Organizational Identities of all COUs the user is an admin
- CoPetitions should be an aggregate of the CoPeople of the COUs the user is an admin
- My COU Population entries should be reconstructed. A long list of My COU Population items will make the side menu very unfriendly.
- Provide Access to Configuration tasks related to COU tasks
- Create COU with default parent COU the one the user is an admin of
- Add CO and COU scope to Attribute enumerators. A COU Admin should not be aware of the roles available in the entire CO
Default configuration should be set to be privacy protecting.
Will also need to create a transition plan/documentation.
Community Impact
It is our understanding that the proposed changes will improve the overall experience for COManage Users. On the other hand, we should take into consideration existing deployments that have different organizational structure and looser privacy needs than the ones we presented above. Not all organizations need or want to have silos between the COUs. For this reason the overall functionality should be configurable, so as to much different needs from different communities
Urgency
The European Data Protection Regulation is applicable as of May 25th, 2018 in all member states to harmonize data privacy laws across Europe. According to GDPR regulation Personal Data are any Information which are related to an identified or identifiable natural person.
The data subjects are identifiable if they can be directly or indirectly identified, especially by reference to an identifier such as a name, an identification number, location data, an online identifier or one of several special characteristics, which expresses the physical, physiological, genetic, mental, commercial, cultural or social identity of these natural persons. In practice, these also include all data which are or can be assigned to a person in any kind of way. For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data.
Currently, COU Admins have access permissions over the entire population of a CO. These access rights violate the aforementioned article and according to EU legislation this can lead to very high fines.
Consequently, we identify the actions that emerge from this proposal as very urgent.
Links
- CO-505 Review COU Admin Privileges
- CO-1156 HelpDesk Authorization Level
- CO-1524 Record and Attribute Release Policies
- COmanage: Proposal Template & Rubric
- COmanage Permissions Policy (CCWG-9 Implementation Wise)
- Consent-informed Attribute Release
- Permission Management Enhancements
Case Studies
ORCID
According to ORCID, the user can choose the visibility for the entire Biography or for each Record in the Registry other than the ORCID ID. The privacy status has three available states:
- visible to everyone
- COmanage => Visible to the whole CO
- visible to trusted
- COmanage => Visible to the COU members the CO Person is a member
- visible only by me
- COmanage => Visible only by the CO Person
The user will choose the default visibility during registration.
- COmanage => This could be an EOF Form field. It could refer to the whole profile of the user or/and per section
According to Linkedin the user could either has his profile completely hidden from the outer world or hide individual sections.
