Sage has determined that key data donors will not share data unless that those accessing the data electronically (1) have provided verifiable identity information and (2) are open/transparent to the public about who they are. Sage has further determined that valid researchers are willing to meet these terms if the verification process is not unduly burdensome or requires divulging sensitive personal and/or financial information. The process has to introduce an appropriate level of friction to obtaining access to data and be reasonably (if not perfectly) able to differentiate between valid researchers and others.
Currently Synapse allows anonymous account creation. Synapse does support "tier 3" access restrictions which can be used to require would-be data accessors to submit documentation justifying data access to the Synapse Access and Compliance Team (ACT). This mechanism could be used to submit identity verification information. However, since identity verification and transparency is a common requirement for many data sets, it would be helpful (both to researchers and the ACT) if each user would only have to do this process once to meet the access requirements for many data sets.
Synapse allows users to complete a user profile but the information may be changed at any time. If identity transparency is a requirement for data access, we must make the verified identity information visible while users have access to the donated data.
To be transparent a user must provide: name (first and last), organization, location (including country) and ORCID.
Approach
Notes
In the proposed approach there's no batching of verification. there's no dashboard to show who is / isn't verified. The information for each user is on a page in Synapse. The work list is the ACT email inbox.
Workflow details
Audit Workflow
ACT performs quarterly audit, starting from a list of users from the data warehouse.
ACT visits user's page, opens up submission which shows submitted info, email addresses, documentation, date approved and by whom.
ACT reviews and clicks "Rescind verification."
Users page now shows "Verification rescinded on xx/xx/20xx."
Future: Need TOU AR gated on being certified and verified.
Questions
does verification require renewal after a set time? NO
does ACT need to 'update' verification? I.e. is it possible to verify but later to need to verify again to capture updated information? YES
what sort of review is required later? E.g. will ACT need later to review the information used to decide to verify someone? Yes need to audit re-verify with new information (newly submitted document)
Does the ACT need support for revoking verification (e.g. if the user deleted their identifying info from their user profile)? Yes, but not for the example given.
Do you need to compare the info at the time of verification to the info at the current time? Don't need to do it automatically.
Portal changes
On user profile page:
Entity page:
Services NOTE THE FOLLOWING NEED TO BE UPDATED
Description | Intended User / Authorization | Notification sent to | URI | Method | Request Parameters | Request Body | Response Body |
---|---|---|---|---|---|---|---|
Request verification. Can only request if there isn't already a pending request. Content must match user profile, emails, ORCID in system at the time the request is made. Rejected if required fields are blank. | any authorized user | ACT | /verificationSubmission | POST | -- | VerificationSubmission | VerificationSubmission |
Get a list of pending (not yet approved) verifications. | ACT | -- | /pendingVerifications | GET | -- | -- | List<VerificationSubmission> |
Get a single verification submission. | ACT | -- | /verificationSubmission/{id} | GET | -- | -- | VerificationSubmission |
Reject verification request | ACT | user who requested verification | /verificationSubmission/{id} | DELETE | reason | -- | -- |
Approve verification submission | ACT | user who requested verification | /verificationSubmission/{id}/approval | PUT | -- | -- | -- |
Retract verification (submission must be approved) | ACT | user who requested verification | /verificationSubmission/{id}/retraction | PUT | -- | -- | -- |
Get UserBundle If not self or ACT then private fields are cleared. | Public | -- | /user/{id}/userBundle | GET | -- | -- | UserBundle |
Link the user ID given by an oauth2 provider to a Synapse account. | any authorized user | -- | /oauth2/alias | POST | -- | OAuthValidationRequest | PrincipalAlias |
Download attachment from verification submission. | ACT | -- | /verificationSubmission/{id}/file/{fileHandleId} | GET | redirect | download URL |
VerificationSubmission:
VerificationApproval:
VerificationRetraction:
UserBundle: