In the diagram:

• The "photo verification service" is provided by an external vendor called Software Secure.

• At the reverification checkpoint, users submit photos of their faces, which the photo verification service compares with photos of the user’s government-issued photo ID.  Users submits ID photos during an "initial" verification process after enrolling in a course.

• Users are allowed to resubmit (shown as a dashed line) only if the assessment is open and the user has not exceeded the attempt limit, which is configurable per-checkpoint.

In its current implementation, in-course reverification does not prevent users from accessing exam content before they submit photos for verification.  Before we release this feature, we need to introduce an access control mechanism that can handle the following cases.

1. ICRV controls access to exam content.

1. When a student reaches an ICRV checkpoint, the student does not have access to exam content.

2. When a student skips (by clicking the "skip" button in the ICRV XBlock) or submits a reverification attempt (by completing the ICRV reverification flow), the user is allowed access to exam content.

2. Enrollment mode controls access to ICRV.  When the student is not enrolled as "verified", all ICRV blocks should be hidden and the user should have access to all exam content.

3. ICRV controls access to other ICRV blocks.  When the student has failed or skipped an earlier ICRV verification, all later ICRV blocks should be hidden and the user should have access to all exam content.

This document presents a design that satisfies these requirements.  The design attempts to balance:

• Course Author UX: It should be easy for course authors to add in-course reverification checkpoints to a course.  In slightly more pessimistic terms, ICRV should be difficult to misconfigure.

• Encapsulation: As much as possible, business logic specific to the verification process should be encapsulated from the core of the system.  One way to achieve this is to re-use existing access control mechanisms, which are likely to provide better interoperability, performance, and security while minimizing development time and complexity.

Proposal

We propose a solution built on group-based access control for courseware content:

1. Implement a partition scheme that assigns users to groups based on their verification status and enrollment mode.

2. For each in-course reverification XBlock in a course, define a partition with three groups:

1. non_verified

2. verified_allow

3. verified_deny

3. Set the allowed groups for the ICRV XBlock to ["verified_allow", "verified_deny"]

4. Set the allowed groups for gated content to ["non_verified", "verified_allow"].

To minimize course author configuration, steps (2), (3), and (4) occur automatically when a version of the course is published. 

To illustrate this, we consider an example course after it has been published:

On course publish, new user partitions will be added to the course for each in-course reverification checkpoint.  If there are existing partitions for checkpoints that have been deleted, they will be removed.

Reverification checkpoints are uniquely identified within a course by the location of the ReverificationBlock.  To minimize course configuration outside of Studio, we propose extending the "User Partition" schema to include a new dictionary field called "parameters".  This field can be used to pass information to the partition scheme -- in this case, we will use it to pass the location of the ReverificationBlock so the partition scheme can locate the associated reverification checkpoint.

{
    "version": 3,
	"id": "abcd1234",
	"name": "Verification Checkpoint for Midterm A",
	"description": "Verification Checkpoint for Midterm A",
	"scheme": "verification",
    "parameters": {
		"location": "block-v1:edX+DemoX+Demo+type@reverification+block@f02a238efac644e389e930fbf275953e"
    },
    "groups": [
         {
             "version": 1,
             "id": "non_verified",
             "name": "Not enrolled in a verified track",
         },
         {
	         "version": 1,
	         "id": "verified_allow",
	         "name": "Enrolled in a verified track and has access"
         },
         {
	         "version": 1,
	         "id": "verified_deny",
	         "name": "Enrolled in a verified track and does not have access"
         }
	]
}

def get_group_for_user(cls, course_key, user, user_partition):
    checkpoint = user_partition.parameters[“location”]

	if (
        not _is_enrolled_in_verified_mode(user, course_key) or
        _was_denied_at_other_checkpoint(user, course_key, location)
    ):
		return NON_VERIFIED_GROUP
    elif (
         _has_skipped_any_checkpoint(user, course_key) or
         _has_completed_checkpoint(user, course_key, checkpoint) or
         _has_preview_permission(user, course_key)
    ):
      	return VERIFIED_ALLOW_GROUP
    else:
	    return VERIFIED_DENY_GROUP