Add Extensibility Mechanisms to IDV to Enable Integration of New IDV Vendor Persona

[MichaelRoytman]

Abstract

The goal of this initiative is to fix a pain point. 2U would like to replace the identity verification (IDV) vendor it uses. Our solution is to leverage existing and add new necessary extensibility mechanisms to support a 2U-specific integration with a new IDV vendor, Persona. This will require changes to the platform to enable this integration. Our proposal outlines how we think it would be best to accomplish this, but we're seeking guidance on how best to do this. Our integration with Persona may need fewer extensibility mechanisms than would be necessary for an Open edX operator to integrate another IDV vendor, because 2U uses IDV to a lesser extent than is supported by the platform and because we are moving photo collection off platform.

Detailed Product Proposal

Proposal

Context & Background (in brief, if a Product Proposal is linked above)

The platform supports a custom integration with Software Secure for IDV. 2U would like to replace the IDV vendor it uses for IDV with Persona. 2U uses IDV only for the Name Affirmation feature, which is a feature that requires certificate-bearing learners to perform IDV when they change their profile name or verified name in specific ways. 2U does not use IDV to block certificate generation nor does 2U require IDV as part of the upgrade process. Open edX operators may choose to enable blocking certificates on IDV via a Django setting, and they may choose to disable the Name Affirmation feature. It is unclear to us how IDV is used by the community and what features or integrations are necessary to support an extensible approach. We asked in the Discuss forums and did not receive much feedback yet. There are some 2+ year old Discuss forum posts regarding various parts of the IDV feature that have some feedback.

Scope & Approach (in brief, if a Product Proposal is linked above)

The general scope of this project is to add the necessary extensibility mechanisms to integrate additional IDV implementations into the platform in the vast majority of uses of IDV. These are detailed in the proposal.

Value & Impact (in brief, if a Product Proposal is linked above)

The value of this proposal is that it would enable the addition of additional IDV implementations to the platform.

Milestones and/or Epics

We have 3 milestones relevant to the community and Axim.

• Backend Extensibility
• Frontend Extensibility
• Refactoring

These are detailed in the proposal.

We have additional milestones related to 2U specific code (e.g. backend and frontend plugins).

Named Release

S

Timeline (in brief, if a Product Proposal is linked above)

This project is high priority and will be started as soon as possible. We would target the S named release. We estimate around 6-8 weeks of implementation.

Proposed By

2U

Additional Info

Proposal

[github-actions[bot]]

Thanks for your submission, @openedx/openedx-product-managers will review shortly.

[sarina]

I think I'll volunteer to be the coordinator of this product proposal, since it may cross with DEPR and engineering in interesting ways. I don't know enough about IDV to review it myself but I'm going to give it a readability check now, and as people come back I'll be pinging them as well. Do you have a snse @MichaelRoytman who might be good to get a review from (either a person specifically, organization, or job function)?

[MichaelRoytman]

Hi, @sarina. Thanks for the update!

As a quick update from me, I have done quite a bit of discovery since originally submitting this proposal and now have a clearer sense of what sorts of changes I'd like to propose making to the platform to enable a 2U-only IDV integration. I'm planning to update the proposal linked to this ticket to add those details. I'm still very much open to community feedback about the role of IDV and for suggestions for extensibility mechanisms, but I now have a proposal for how we could extend the platform to integrate Persona on edx.org. I'll try to finish updating the document by the end of day or early morning tomorrow - just wanted to give you a heads up if you'd prefer to hold off on reading it until then.

My team, the Cosmonauts, is the owning team for IDV, so we're likely the subject matter experts on the feature. My proposal involves the use of the hooks framework to provide extensibility on the backend, so maybe Maria Grimaldi and Felipe Montoya, as you recommended in Slack? For the frontend, my proposal involves the use of the frontend-plugin-framework, and I think Adolfo and/or Brian are involved in that initiative.

Otherwise, the only users of IDV that I know of are EDUlib and OpenCraft - perhaps a representative from those two organizations, especially if we begin discussing deprecation? I don't think they'd necessarily have an opinion on the extensibility mechanisms, though, so if the discussion will stick to that, it might not be necessary to loop them in.

Does that help?

[sarina]

Thanks @MichaelRoytman - I will hold off on reading until then.

If your work entirely leverages plugins, and you're not intending this to be a global/community solution, the implementation of Persona is not likely a thing that requires review. What would require review is altering or removing the existing implementation, the latter of which would fall to a DEPR ticket.

edulib no longer leverages the Open edX platform. I can reach out to OpenCraft to get someone to chime in on changes to existing functionality.

[MichaelRoytman]

@sarina The document is ready for review!

Our current proposal is just to add to the extension points to the platform necessary to hook in an additional IDV implementation. You're right that we would not include any 2U or Persona related implementation code in the platform - that would be private. We aren't currently recommending any deprecation.

That's good to know about EDUlib. Thank you!

[sarina]

@MichaelRoytman seems good to me. The product proposal and the DEPR would be two separate processes anyhow. I would strongly recommend you file the DEPR ticket and open it for discussion - filing the ticket (I believe! you can check with Diana) doesn't commit you to doing the removal, but is a signal that the code is effectively unmaintained which I think is important here.

Next steps: I'll mention this at the Core Product WG with my and Dave's recommendation to move forward. Hopefully we'll get another reviewer quickly.

[MichaelRoytman]

Thank you, @sarina! I reviewed your feedback on the doc. I'll address your feedback and open the DEPR ticket tomorrow.

[sarina]

Thanks to @marcotuts for volunteering to take a look at this.

[marcotuts]

I read through the Confluence page and there is a ton of detail and thoughtful writeup here, thanks @MichaelRoytman! (and also anyone else who worked on this 🔥 ) From my perspective this feels like a great step forward for the platform and makes use of modern architectural patterns that support extensibility moving forward.

👍 - Product Review

I was mostly surprised while reviewing this how many better mechanisms are in place via plugins / hooks / filters / slots, etc to make this kind of functionality easily swappable in the future. Progress!

Separately, it does seem like this project exposes a whole mountain of potential or planned deprecation efforts.

I know that is separate from this proposal but it seems like this project would benefit from being featured in a DEPR working group meeting or two if it hasn't been already. :) Lots of potential cleanup value here!

I also appreciated that the team considered what deprecation of certain items could mean for other instances using hooks / filters today. It might be helpful to have @mariajgrimaldi give this a look through to see if there are any related django hooks / filters that might be impacted or improved by work done here, but that's not a blocking concern.

[MichaelRoytman]

Thank you, @marcotuts!

Regarding the DEPR process, I have logged a DEPR ticket for the Software Secure integration: https://github.com/openedx/edx-platform/issues/35128. Do you recommend that I follow the standard DEPR process for communicating this DEPR and gathering feedback?

As you noted, there is a lot of opportunity for cleanup here, but I did not create a DEPR for all the parts of IDV that may make sense to deprecate, because I am focused on Software Secure and do not know how the rest of the Open edX community uses IDV. I could create another DEPR, but it would be "[DEPR] Uh, some of the IDV things?" Let me know what you think.

Also, some of the concrete suggestions in the proposal are in flux, because Dave and I were discussing them. I know Dave will be unable to review the suggested changes I made based on our conversation for a few weeks. Is there someone who could help me tie up those loose ends?

Thanks!

[MichaelRoytman]

@sarina Thank you for shepherding this along. I want to confirm that my understanding of next steps is correct.

1. Marco gave us product approval on the proposal. Does this mean that we are all set to begin implementation?

2. I read through the Open edX Developer's Guide. Is it correct that we'll need approval from a core contributor for these changes to the edx-platform and frontend-app-account repositories? a. 2U maintains the frontend-app-account repository. Does this mean the owning team can review and approve these code changes? b. Who reviews pull requests against edx-platform? Would we ping the committers-edx-platform team?

   Thank you!

[sarina]

@MichaelRoytman thanks for checking in.

1. Yes, you are set to begin implementation. Thanks @marcotuts for the review.
2. You will need approval from someone who has write access to the repo. In most smaller repos, the maintaining team is defined in catalog-info.yaml (see frontend-app-account). In edx-platform, yeah it's a bit unclear who you'd tag, but starting with that team would work, although it isn't comprehensive as to who has approving access. I'd probably tag that team as well as Dave.

[MichaelRoytman]

@marcotuts We've made a few small tweaks to the proposal. I understand we need to have them reviewed, since they deviate from the originally approved proposal. Could you review them, please?

The only learner facing change is documented in the Name Change Modal section, but the entire Refactoring section is relatively new based on my discussion with Dave.

Thank you!

[marcotuts]

All set on my end, thanks for pointing out the specific customer facing changes!