...
(3) The user receives the email and is instructed to include it with their NRGR application. If the user is the head of a lab, then each lab member wishing to access the data must perform step (1) and the applicant must include all the emailed tokens with the NRGR application.
(4) Upon approval of the applicant(s), the token email(s) are sent to a predefined email address. The email includes a digital signature, authenticating it as being sent by the NIHan X-Originating-IP header, showing it as originating from the NIMH.
(5) Upon receipt of the email, the digital signature in validatedX-Originating-IP header is checked, the tokens are extracted, and their HMACs validated. Since the tokens are time stamped, a time limit can be imposed, ensuring out-of-date requests are rejected. The tokens' contents are used to generate Access Approvals in Synapse, unlocking the data for those approved in NRGR. The applicants are added to the data access group. Email notification alerts the applicants to the completion of the process. The Synapse table record created in step (2) is updated, providing the Synapse Access and Compliance Team (ACT) a dashboard of approval progress. If a token is rejected (e.g. if the data is corrupt, the token is too old, or the signature is invalid), this is noted in the table. If the applicant's Synapse user ID can be discerned from the record, an email notification rejection notice is sent to them.
Exceptions and Edge Cases
A new Synapse user in a previously approved lab: The NRGR approval process considers an entire lab to be approved once a lab P.I. has completed their process. Thus a new lab member may request access without involving NRGR. In this case we require the new user to perform step (1) and for the authenticated PI to provide the token to the ACT, which is authorized to trigger step (5), bypassing the email from NIH. NIMH.
Rejected token for an identifiable user: In some cases a token is rejected but the Synapse user ID of the applicant can be extracted. We expect this will most commonly occur when the time stamp in the token has expired. In this case the applicant is instructed to generate a new token and forward it to the Synapse ACT who will then contact NIMH to verify the applicant's approval and use their authority to approve the data access.
Adding new data to be governed by this process:
Case 1: A new data file or folder is added to the existing data set, and is to be retroactively made available to all currently approved users (as well as new ones).
Solution: No change to the approval process is needed. We simply modify the existing Access Requirement to govern the new data items as well as the currently governed ones.
Case 2: New data is placed in Synapse. NRGR policy requires the following in this case: Currently approved users need additional approval to access the new data. New users require one approval for both the old and new data.
Solution: A new Access Requirement is created in Synapse, governing the new data (but not the existing data). The token generator is modified to reference both the old and new Access Requirements. All users (approved and new) are instructed to go through the approval process which, when complete, will approve users for both the old and new Access Requirements.