...
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. 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 receives suggestion that verified information is inaccurateperforms 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 "Remove Suspend verification."
Anonymity Request Workflow
User emails ACT requesting anonymity be restored.
ACT visits user's page, clicks "Remove verificationUsers page now shows "Verification suspended on xx/xx/20xx."
Future: Need TOU AR gated on being certified and verified.
...
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).
...
- 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 NOTE THE FOLLOWING NEED TO BE UPDATED
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 | |
|---|---|---|---|---|---|---|---|---|---|
| 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 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 | ||
| Add ORCID to account | Link the user ID given by an oauth2 provider to a Synapse account. | any authorized user | -- | /authoauth2/orcidalias | 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
...
| 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.