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
- User visits Synapse page for sensitive data (e.g. the Bridge data).
- User sees that data is Controlled (tier 3)
- User opens dialog, showing text for the access restriction, e.g. "Please become 'verified' (following instructions on your home page), and send a description of how you intend to use this data along with the Synapse ID of this data to SynapseAccessandComplianceTeam@synapse.org".
- User visits home page.
- User clicks link "Become Verified".
- Portal sends user to wiki that contains instructions... "Complete your user profile including name, organization; link your ORCID; then email SynapseAccessandComplianceTeam@synapse.org, including a completed ID verification document."
- User completes user profile and emails ACT, including ID verification document and data use statement.
- ACT receives email. From the user's Synapse user name (the prefix of the 'from' email address) ACT member determines the ACT management page https://www.synapse.org/#!ACTVerify:<username>.
- ACT reviews ID verification document and user profile.
- ACT member clicks 'Verify Identity' on verification page.
- Synapse captures snapshot of reviewed information (VerificationBundle, below), records that user is verified, sends notification to user.
- "Verified" now appears on user's page. "Verify Identity" changes to "Remove ID Verification" on the ACT Page.
- User receives verification notification.
- ACT visits page for sensitive data, clicks "Grant access", finds the user based on their user name, and clicks "OK".
- User is notified that they are now granted access.
- User tries to access data, is prompted to reaffirm oath. User agrees.
- User can now access data.
Future: Need TOU AR gated on being certified and verified.
Open 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:
- Alert for unverified users with link to new help page (wiki).
- UI to show user is verified.
- New ACT place(page) to show VerificationBundle and Verify/"Remove Verification" button
- Changes to support new profile field(s). Use UserBundle in both the user profile page and the new ACT page.
- Need to verify that a wiki can be created where links are popped up in a new browser window (so that the instructional wiki is a launching point). Need to support a way to link to current user profile page (special token, like "myself" that pushes the correct url into the browser history).
Entity page:
- Ability for ACT to "grant access". This command needs to prompt for a user id, and then find an ACT terms of use for the currently shown entity. If successful, then it should create an access approval using this pair.
Services
| Description | Intended User / Authorization | URI | Method | Request Parameters | Request Body | Response Body |
|---|---|---|---|---|---|---|
| Retrieve the information used to verify a user. | ACT member | /user/{id}/verificationInfo | GET | -- | -- | VerificationBundle |
| Verify a user. | ACT member | /user/{id}/verification | POST | verificationBundleHash | -- | VerificationBundle |
| Retrieve verification info | ACT member | /user/{id}/verification | GET | -- | -- | VerificationBundle |
| Remove verification | ACT member | /user/{id}/verification | DELETE | -- | -- | -- |
| Get UserBundle | Public | /user/{id}/userBundle | GET | -- | -- | UserBundle |
| Add ORCID to account | any authorized user | /auth/orcid | POST | -- | OAuthValidationRequest | ORCID |
UserBundle:
- isCertified
- isVerified
- hasSignedTOU
- isACTMember
- isAdmin
- userProfile
- ORCID
VerificationBundle:
- createdBy
- createdOn
- isCertified
- isVerified
- hasSignedTOU
- first name
- last name
- organization
- email addresses
- ORCID
- verificationBundleHash