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!
@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.
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.
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).
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.
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.
@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).
Thanks for reaching back!
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?
Currently running Nutmeg on a test server and I can clearly see that IDV through photo ID verification is sill being used.
Will it still be available in Olive?
If not, how do we verify the student identify going forward for paid verified certificates? I saw a few references to simply accepting the Honor code. How will that be different than for Honor certificates we deliver without requiring payment or photo ID verification going forward?
Dear All, sorry to hijack this discussion, but my question is related. We have just started to use a self-hosted instance of Open edX and right before the official launch, the Photo Verification Requirements screen suddenly appeared. We don’t need a verification at all, but I can’t figure out where to turn this off. Could you please point me to the right direction? Thanks
for continuing the deprecation process for the current mechanism.