Technical Approach for LTI redesign

Owned by Felipe Montoya
Last updated: Dec 05, 2024 by Maria Fernanda Magallanes Z
6 min read

After an in-depth discussion on the LTI redesign, this document outlines the technical steps required for implementation and the planned iterations for development.

The final version of the project lists as objectives:

  • Facilitate the process of adding LTIs for administrators and course creators.

  • Create the flow of reusing LTIs in a friendly way

  • Adapt to make it easy to use for all types of users, from zero experts to the most experienced users.

Turning this into tasks there are many interventions that we will need. As this might be a long project we are already suggesting to do this in phases where we prioritize for impact and low cost.

Index

Technical Approach for LTI redesign | Ongoing work

Technical Approach for LTI redesign | LTI Consumer XBlock Enhancement

Technical Approach for LTI redesign | Decouple LTI configuration from LTI xblock

Technical Approach for LTI redesign | Dynamic registration

Technical Approach for LTI redesign | Centralized admin tool

Ongoing work

in progress

To be defined, but on Nov 26, 2024, in the LTI WG meeting, we discussed prioritizing the Decouple work because it brings more long-term impact.
Another option is to select two features from XBlock Enhancement and make the discovery of the Decouple part to have UX improvements and time for a proper discussion about the discovery. Then, in another part of the work, implement the decouple.

LTI Consumer XBlock Enhancement

To do

The first phase involves enabling course authors to reuse LTI tools (including those with LTI 1.3) using the existing “Copy to clipboard” and “Duplicate” features in Studio. Additionally, a new interface will be introduced to make the implementation of the LTI tool more user-friendly.

1.1. Alter studio such that lti_consumer xblock is active by default and such that a new component button is available.

The function to load lti_consumer as an xblock for courses would default to true, but ideally this decision should be overridable at the instance or course level. The easiest way to handle this would be to use a waffle flag.

 

1.2. Graphical editor for the xblock

In this phase, the graphical editor would include the necessary steps for inserting a new lti consumer xblock.

image-20240823-231614.png

At the present time we see two ways of creating such an editor.

  • Using the course-authoring MFE

  • Creating a React based editor for the xblock

Both of them require doing some work on the modal that would hold the editor.

 

1.3. Fix the re usability with the current tools

There are currently 2 ways of reusing a component in open edX:

  • Duplicate

  • Copy paste

Neither of them works because with the current implementation of lti_consumer xblock the client ID changes for every added component. Each client_id needs to be added back in the tool provider and this makes LTI1.3 very annoying to use.

Updated:

Talking directly about the plan for allowing the copy to clipboard and duplicate features, fixing the deployment_id constraint, and allowing the multitenancy in LTI could bring flexibility. Still, it doesn't solve the reusability problem because the standard flow of the creation of the tool is connected directly with the xblock and has constraints with the client_id (it should be unique) and auto-generate keysets for providing the Keyset URL and Access Token URL of the platform.

In Moodle, the client_id is unique by tool, not for component, and the credentials (Keyset URL, Access Token URL, and Login URL) don't change, and they maintain their values through the platform.

…

The first thing we need to do to allow reusability is maintain the credentials: maintain the Access Token URL; we don't have a problem with the Login URL because we already preserve that. We could keep the Keyset URL as Canvas and Moodle, but I like the LTI® v1.3 Reference Implementation Test Tool by IMS (https://lti-ri.imsglobal.org/ ) approach. In the reference, you can create platform keys with a name and a deployment_id, and based on that key, you can obtain a related Keyset URL. With that approach, we can have, for example, a key for the math department and say that the deployment_id is 2, and use that key for all the math department tools, so if some departments want to use the same tool, each one has their deployment id so the tool can identify that the authentication comes from the same platform but with different deployment and configure their behavior based on that.

Note: this approach is more resilient if some key is compromised; we can create another that only affects a department and not all. Or use one key, and that's it.

For more info about this approach: Re: Technical Approach for LTI redesign | Comment

Old proposal:

This comes from the current implementation of Single Tenant mode of the LTI Deployment. The refactor of this xblock should allow the usage of both Single and Multi Tenant Deployment (completely unrelated to multitenancy in the lms). With this change it should be possible to reuse the same ClientID and to pick the deployment ID according to the usage of the tool (some institutions use the same deployment ID to separate courses, organization or things like the university department).

 

1.4. Fix the render for 1.3

Partly related to the previous point, when using LTI 1.3, the student_view rendered in studio only shows the configuration variables instead of the rendered LTI component which forces authors to publish and visit the unit in the LMS. We must address this to have both a way to see the final variables as well as the actual render.

1.5. Documentación

The current documentation needs to be updated to include the new LTI tool implementation features, along with detailed step-by-step examples for integrating common tools.

Decouple LTI configuration from LTI xblock

To do

Decouple the model to have an LTI config part and an xblock part; the xblock LTI depends on the LTI config but not the other way. This proposal also aligns with what 2U commented in the Boston conference about the next steps of the work on LTI. However, this requires ADRs and discovery because we will affect how it works and must figure out how to mitigate possible problems.

Milestone 1: Technical Discovery for decoupling LTI configuration from LTI xblock

  • Unambiguous technical recommendations;

  • Rationale used to reach conclusions in clear and concise language, including code samples and other visual aids where appropriate; and

  • Explicit references, including but not limited to citations from other sources or results from experimental findings, to support said recommendations.

Deliverables: 

  • Detailed documents containing the findings of the technical discovery as specified above;

    • These documents will be one or more draft ADRs in the relevant Open edX or (new) Plugin repositories.

  • A live or recorded presentation of the discovery's findings.

Milestone 2: Reference Implementation

  • Documentation for how to create an LTI configuration (register a tool), and how we can use it in the LTI xblock.

  • Any code or configuration changes needed to decouple the LTI configuration from the xblock, and be able to use the configuration in the xblock.

Deliverables:

  • Code in the xblock-lti-consumer repository that allows LTI configurations without an associated xblock component and allows the xblock to use those LTI configurations.

  • Technical documentation pertaining to the specifics of the reference implementation.  For example:

    • README files describing architectural decisions

    • In-code comments explaining implementation details

    • Meaningful commits with messages that explain the essence of each change-set

    • Suggested updates to existing architectural decisions and OEPs

    • Suggested future work to support any error handling or disaster recovery scenarios not included in the reference implementation

    • It should make use of the Open edX plugin system, as well as the events and filters mechanisms where possible.

  • A live or recorded demonstration of a running instance of the complete reference implementation.

  • Update the course author documentation.

Dynamic registration

To do

Dynamic registration Learning Tools Interoperability (LTI)® Dynamic Registration Specification v1.0 | IMS Global Learning Consortium

Centralized admin tool

To do

Centralized admin tool

 

Other references related

Links and references: