Deprecation/Removal: ID verification as a cert requirement

Continuation of this thread from last year: Deprecation/Removal: ID Verification flow in edx-platform

Summary:
We plan on deprecating ID verification as a course certificate requirement. We’d like to hear your feedback and concerns.

Context:
edX will be disabling ID verification as a requirement for certificates and proctoring in January. Instead of going through the ID verification flow, learners enrolled in a verified track will simply reaffirm their agreement to the Honor Code before being able to complete graded assignments in the course. Visual elements related to IDV (IE verification status on dashboard, course home, etc) will be removed.

However, ID verification will not be removed from the platform completely. In order to preserve integrity for certificates, we’re also introducing a Name Affirmation feature. If a learner changes their name after earning a certificate, certain changes may prompt the learner to complete ID verification before the name change is accepted. This is available as an optional plugin for edx-platform, found here: https://github.com/edx/edx-name-affirmation

What this means for open edX:
verify_student will still exist, but as an optional feature along with Name Affirmation. We plan on deprecating the legacy UI views entirely. The submission API, models, and database tables will still exist.

In the interim, the course requirement for IDV is controlled by a toggle, but ideally we’d like to deprecate this requirement completely and replace it with the Honor Code agreement.

My question is: Are there any concerns with removing IDV as a course requirement and adopting these features? We’d like to come up with a solid timeline on this deprecation, and all feedback helps. Thank you!

@giovannicimolin and @sambapete do you have thoughts here?

Currently on sick leave but I’ve forwarded the topic to one of my colleagues who will look into it.

@schenedx @bseverino Currently, the ID verification blocks certificates from being issued until a user performs the account verification.

If possible, along with the deprecation, we’d like some mechanism that still allows that to happen (even if it’s implemented by the community and upstreamed).
One viable approach I see is to use the new Hooks & Filters extensions to make the certificate generation run a filter pipeline before issuing the certificate. A filter could then hook into that pipeline and block certificate generation (in case a user didn’t verify his account on the plugin), transform user metadata, etc then relay information (errors/messages) back to the user.

:+1: for continuing the deprecation process for the current mechanism.
Just make sure the removals are announced and the community is given time to plan + implement a replacement approach.

Hi @giovannicimolin - thank you for your response. Just to clarify, the only blocker in this case is adding a check for account verification (not to be confused with photo ID verification) before granting certificates? I’ll bring this back to the team so we can look into ways to replace this functionality, including your suggestion.

@bseverino

Just to clarify, the only blocker in this case is adding a check for account verification (not to be confused with photo ID verification) before granting certificates?

Not really. If possible, we want a way to check the ID verification before granting a certificate through a pluggable mechanism.
My suggestion above considers that the ID verification functionality is removed entirely from the platform but there’s a mechanism in the LMS that allows plugins to block certificate emission (through a filter pipeline).

1 Like

Hi there. We are currently integrating proctored exams into our site: https://mitxonline.mit.edu/ – it appears to be utilizing Name Affirmation to validate learner’s names. While I can appreciate the additional security provided by this functionality, we would like to allow learners to be able to change their names directly. Is there a way to configure the Name Affirmation to give learners the ability to update their names for proctoring on their own? Or possibly a way to circumvent the Name Affirmation functionality?

Hi Brian - there is currently no way to get around this on the master branch, though we are looking into making this feature optional.

In the meantime, learners can still take proctored exams without waiting for approval; once they submit a name change, edx-proctoring is configured to use the “pending” name for verification.

Thanks for finding this, @bseverino and replying!

Note that there was a very helpful Slack thread on this topic here: Slack

1 Like

Hi @giovannicimolin, we are looking at using the hooks and filters extensions to provide open edX instances with way to continue blocking certificate generation, but remove other IDV references completely on the course dashboard and proctoring.

I know you had suggested using hooks and filters, but wanted to circle back to make sure that you still agree with this approach.

Thanks!

2 Likes

@alangston Yes, the approach makes total sense (no need to keep specific IDV flows when we have a generic mechanism that can do the same thing). :+1:
Thanks for reaching back!

1 Like

Good afternoon!

The team is currently in the process of attempting to remove IDV as a gate for certificate generation in the edx-platform while also providing a way for the community to maintain this feature.

Currently, the edx-platform supports certificates that are not in the “downloadable” status. These statuses include “unverified”, “notpassing”, and “unavailable”. These statuses exists within the platform solely to aid our support team when working with certificate support issues.

My question to you is: do you rely on the “unverified” certificate status? If we were to remove the concept of an “unverified” certificate, would this be an issue for you?

Please let me know.

Thank you!

Yes, because we look in the database in order to remind users to do their IDV if they have already paid for a certificate and haven’t done so.

And it does work because some users do their IDV right after receiving an email from us.