...
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.
...
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.