LTI Provider Architectural Direction

Overview

This page is meant to give a current and accurate description of the architectural direction of a subset of the LTI Provider functionality of edX.  Unless explicitly stated otherwise, the terms OpenEdx, edX, and edX platform may be used interchangeably throughout this document.

There are many useful documents reachable from the LTI Space Home Page, but they require curating to bring them up to date.  While that will be an ongoing process, some topics have bubbled up in the community and will be addressed here.

LTI Resources and Courses

LTI resources served from the edX platform (e.g. problems, units, subsections, chapters) are meant to be consumed as small components hosted by an external LMS (the LTI Consumer).  According to the basic relationship set up by the LTI Specification, it is the responsibility of the external host LMS (the LTI Consumer) to determine the relationship between these individual resources and any concept of a course.  Edx as an LTI Provider cannot make any statements about collections of LTI resources as a course in the external LMS.  The fact that these LTI resources, according to the current implementation in edX, are also created in the context of an edX course is not called for as part of the LTI Specification.  According to the original edX as LTI Provider architecture document, this decision was made in part because it "...greatly simplifies the user management and [resource] permissioning model...".

As stated in this same architecture document, based on the current implementation of edX as an LTI Provider, it is still currently recommended to use a separate edX course for these LTI resources.  It is also recommended that the course should never be used by non-LTI users.  

However, based on the above discussion of the roles of LTI Consumer and LTI Provider in relationship to a course, the future architectural direction of LTI resources inside edX should allow for the loosening of this dependency.  Any requests or decisions that couple LTI resources served through edX as an LTI Provider even more tightly to an edX course leaves less flexibility around this functionality by making assumptions about the grouping of this content that may not be true in the future.

One such request was to enroll LTI users in the edX course used in the current LTI Provider implementation.  This would more greatly couple our LTI Provider implementation to edX courses.  The original architecture document details that this enrollment of LTI users was avoided.  However, this document also leaves unanswered question about the future intention of this coupling.  For example, it explains how analytics data is coupled with the edX course, but not why, nor how and if that coupling can equally be loosened.

It is also understood that the single float outcome that is returned by LTI 1.1 may not be sufficient, and an LTI Consumer may require more data from the edX platform in the future.  If other administrative data is required, we will need to discuss APIs that can extend the current implementation through some standard specification, whether that be something from LTI 2.0, or an XBlock-like extension, or some similar standard.  This has not been designed in detail, but is acknowledged here to give an indication of the ways in which the LTI Provider implementation might be extended if necessary.