Verified User

Problem

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

We propose the following process for identity verification:

(1) The Synapse user must obtain a pdf copy of either

1. a letter from a signing official at their organization on letterhead;

2. a notarized letter attesting to the person's identity;

3. a copy of a professional license and web address to verify (for example, a photocopy of my genetic counseling license and a link to the Ohio State Medical Board website);

4. some other document agreed to by the researcher and the ACT.

(2) The user is prompted to fill out their Synapse user profile, including name, organization, location (including country) and to link their ORCID account.

(3) User clicks to open a verification submission form, prefilled with the aforementioned information from their user profile. When complete, they click 'submit.'

(4) An ACT member reviews the submitted information for completeness and consistency. If deemed acceptable the information is saved for future review. The ACT marks the user as "verified."

(5) Synapse displays some or all of this verification information on the page for the verified user. Thus, even if the user modifies their user profile, their identity continues to be transparent.

(6) When later approving "tier 3" data access requests the ACT checks whether the requesting user has been verified.

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. Instructions say, "Fill out your user profile and link to your ORCID then click 'get verified'.
User fills out their user profile, links their ORCID, clicks link "Become Verified".
Page opens showing first name, last name, organization, location, country, from user profile, as well as email addresses and ORCID. Prompts for verification document. Form highlights fields which will become publicly visible (e.g. name and affiliation are visible, emails and attached doc's are not).
User uploads/attaches verification document, clicks "Submit."
ACT receives notification of verification submission.
ACT visits page listing pending submissions, clicks on one, opening up a display of the submission. This page also shows user's email address(es).
ACT may reject submission: Submission is deleted; rejection notification is sent to user (including reason?); User may repeat "Become verified..."
ACT may accept submission:
Submission is marked as accepted.

"Verified" now appears on user's page. Anyone clicking on "verified" sees the name, organization, location, country, ORCID that were verified, plus the date verification occurred.
Notification is sent to user.
User now completes "tier 3" request, sending data use statement to ACT.
ACT receives email, checks that user was verified.
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.

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 "Suspend verification."

Users page now shows "Verification suspended 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

Mockups are available here.

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.

These are the states that a Verification Submission can take on and the transitions it can make:

Services

Description	Restrictions	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 submitted or approved 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 verification submissions.		ACT	--	/verificationSubmission	GET	limit, offset, userId, state	--	VerificationSubmissionPaginatedResults
Change submission state	Allowed state transitions shown in diagram above.	ACT	user who requested verification	/verificationSubmission/{id}/state	POST	--	VerificationState	--
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
Unbind an alias from an account.		owner of the alias		/alias/{aliasType}/{aliasName}	DELETE	--	--	--
Download attachment from verification submission.		ACT	--	/file/{id}?fileAssociateType=VERIFICATION_SUBMISSION&fileAssociateId=999	GET	fileAssociateType (required) fileAssociateId (required) redirect (optional) Note we introduce a new fileAssociateType, "VerificationSubmission".		download URL

VerificationSubmission:

id
userId
createdOn
first name
last name
organization
location
ORCID
email list
attachments (fileHandleIds)
state (one of submitted, approved, rejected, suspended)
stateHistory

VerificationState

createdBy (only returned if user is in the ACT)
createdOn
state (one of submitted, approved, rejected, suspended)
reason (e.g. UserProfile changed wrt V.S., OR ACT initiated the state change)

UserBundle:

isCertified
isVerified

isACTMember
userProfile (public fields for public, private fields for owner)
ORCID
verificationSubmission: if owner or ACT, will be the latest. Otherwise, will only be included if approved and will be scrubbed of private fields.