...
We propose adding support for new permission: EXEMPTION_ELIGIBLE to the AR ACL system. This new permission would allow members of the ACT to grant either an individual user or team, to be eligible for “exemption”, from data access approval requirements. It is important to note that being eligible for “exemption” is not a data access approval. Instead, the DENY_IF_HAS_UNMET_ACCESS_RESTRICTIONS rule would be replaced by: DENY_IF_NOT_EXEMPT_AND_HAS_UNMET_ACCESS_RESTRICTIONS
This new rule would checkbe checked, for each AR bound to the Entity, the . The user must either be exempt or be granted at least one access approval. If a single AR check fails, the request would be denied.
To determine if a user is “exempt” on an AR, a check will be made to determine if at least one of the user’s principals have been granted the EXEMPTION_ELIGIBLE permission on the AR’s ACL, plus one of the user’s principals must be granted the DELETE permission one more permissions on the Entity’s ACL that identify the user as a Data Contributor. If both conditions are not met, the user will not be considered “exempt”. In short, a user must be both eligible for exemption (via ACT) and must be a Data Contributor (via Data Administrator) to be exempt from an AR on a per file basis.
Note: We check the DELETE permission have yet to determine if which permission/permissions define a user is as a Data Contributor because it is not a decision to be made lightly. If the Data Administrators does not trust the user enough to grant them DELETE on the data, then the user should not be eligible for a data request exemption. Only ACT can determine what the appropriate level of permission is needed to bypass the normal access approval process.
Exemption Eligible Team
Given that a single project might have many ARs, it would laborious for ACT add/remove individual eligible users to each AR over the course of a project’s lifecycle. In fact, this might be just as much work, for all users, as the existing system of granting “dummy” submissions. Instead, it would be more convenient for ACT to create a reusable team of eligible individuals. The team would then be granted the EXEMPTION_ELIGIBLE permission on each AR in the project. ACT would then add/remove users from team over the course of the project’s lifecycle. The administrators of such a team would be limited to ACT.
While it is possible that a single team might be reused for multiple projects, it is more likely that truly distinct projects will have their own team of exemption eligible users. This means, Data Contributors would need to leverage to the existing team membership request feature to request exemption-eligibility for each project to which they contribute. Since ACT will be the administrators of the teams bound to ARs, ACT will be notified of all membership requests of these teams. ACT would control the team membership approvals/rejections to manage exemption eligibility.
At this time, we recommend that teams created/used by ACT for the purpose of data access exemptions, be regular Synapse teams. This means the teams will be created using the standard team UI. We should also be able to reuse the existing team membership application UI for Data Contributor membership requests.
ACT will be free to add/remove team administrators from such teams, as they see fit. This would allow ACT to delegate exemption eligibility management to a 3rd party when required.
This proposal does not eliminate the need for a Data Contributor interact with ACT to be able to download files with restrictions. However, for cases where there are many ARs for a project, data access exemptions can be as simple as a single click for both Data Contributors and ACT.
Note: We assume that ACT will be able to share the appropriate team membership application links with Data Administrators, which then in turn, will share the links with their Data Contributors.
We suggest the new teams used for this case have the following limitations:
...
Only ACT can be the administrator of the team. Any change to the team’s administration will be rejected.
...
Action Required
Currently, when a user attempts to download a file (through any of the Synapse download features), they are presented with one “actions required” for each AR that they have not “met”. This is shown to the user in various places in the UI, to aid the user in “meeting” each AR. For the case where the user is a Data Contributor identified by the appropriate permission, we propose extending the “actions required” to include the ID of the ACT managed team/teams. We can then extend the “actions required” UI, to include a link for the user to request membership to the team/teams.
Summary
This proposal provides a new mechanism for Data Contributors to be exempt from data Access Restrictions on data that they are responsible for maintaining. Exemptions are on a per file basis. In order to be exempt, the Data Contributor must be granted the “DELETE” appropriate permission on a file by the Data Administrator. In addition, the Data Contributor must also be granted the “EXEMPTION_ELIGIBLE” permission on a AR by a member of the ACT. In this way, a contribution from both Data Administrators and ACT, determines which files a Data Contributor is exempt. This also means exemption can be revoked by either Data Administrators or ACT at any time without the need to coordinate their actions.
...