Hi all, we in the Program theme is planning to deprecate and remove the UI and its related views and URLs associated with the ID verification flow within edx-platform.
This means:
The verify_student app WILL NOT be deleted. We are keeping the ID Verification feature.
The Koa release branch will be created on Nov 9th. That means when the deprecate merges into master branch, it will need to be cherrypicked to get into Koa release.
I am trying to get this deprecation into Koa release, but I cannot promise that will happen.
Will this be forcing us to use a different user validation method in Open edX starting with Koa? Maybe we need a new process to remove / deprecate something from edX that does not immediately impact Open edX? Especially with the new 6 months between releases. In that case, especially since theming won’t be easily available for MFEs with Koa, I believe the Open edX community needs more time to adapt than the regular DEPR process.
@sambapete and @giovannicimolin
This is exactly what I want to hear. I need to know what ID Verification means to our openedx community and you clearly knows about this in more detail.
Therefore, can you please help me by describing to me:
What are you using ID Verification for? What is the business purpose?
Are you using the same IDProbe backend or a different Verification provider?
If we deprecate this functionality on edx-platform, can you think of alternative method to verify learners?
If edx.org will no longer offer ID Verification functionality on edx-platform codebase, what you think is a solution to help the community make the transition?
We use ID Verification to check the identity of users trying to buy a certificate for a course. As we have our own fork, we intercept the calls to Software Secure and do our own manual verifications.
Different verification provider (ourselves). We modified a few lines of code in order to send the photographs to one of our own S3 buckets and we have a few manual scripts to run in order to check the photographs. We do not keep the photographs after verification. We have been doing this for at least a few releases.
Not at this time…
We would need more time to think about it and a month before the release of Koa is too short notice for us.
in order to emulate what was done for SoftwareSecurePhotoVerification.
We wanted to make as minimal changes as we could but still being able to implement some kind of ID Verification based on the process edX was using at the time.
You can check our modifications in
As I said earlier, we also developed manual scripts to fetch the photographs from our S3 buckets that we can use to manually verify the identity of users.
We did not want to reinvent the wheel.
Changing the process now would be reinventing the wheel on short notice for Koa.
@schenedx I’m off for the next two weeks, so I won’t be able to reply in the Koa deadline. @guruprasad If you have some free time on your sprint, can you reply here?
What are you using ID Verification for? What is the business purpose?
We have a client using it to verify the student IDs, though that is done manually by the course staff.
Are you using the same IDProbe backend or a different Verification provider?
No, we are using the manual verification overrides.
We use the views only to embed a page from a pluggable app, which presents a user verification form and stores data in a custom model. When a staff user “approves” the verification request, then a signal automatically adds a ManualVerification model entry and bypasses the Software Secure requirement.
This was our way to avoid modifying the core, but it’s not the most elegant solution available: it needs the pluggable app + template overrides. The better option would be to have a generic ID verification model in the platform, and pluggability for multiple verification providers, as this would avoid having to rework the UI or do theme overrides.
We’re happy to open source our solution if there’s enough interest.
If we deprecate this functionality on edx-platform, can you think of alternative method to verify learners?
If Open edX provides us hooks to intercept the enrollment process and trigger/redirect to user verification pages, then it’s fine to deprecate the feature.
Also, from my understanding, what you are deprecating here are the views, and not the entire verification functionality, right?
If edx.org will no longer offer ID Verification functionality on edx-platform codebase, what you think is a solution to help the community make the transition?
The suggestion I’ve mentioned above works: having a generic verification models, with the ability to plug in custom verification providers (no complex mechanisms, a python package + configuration variable would work). The feature can be left disabled by default, and edx-platform doesn’t need any service-specific code in the core.
