1. Purpose

Open edX currently supports configuring an LTI tool directly in an LTI Consumer XBlock or referencing a reusable configuration from the LTI Store plugin. Each approach solves part of the problem, but neither provides a complete configuration management experience.

The desired experience is:

Configure a tool once, make it available to the appropriate courses/orgs, use it in multiple places, and manage it easily/safely.

This document describes the expected product behavior and open questions.

Some requirements may be delivered in stages. However, we should try to keep v1 compatible with the long term direction described here.

Open

Information needed to register platform/tool for LTI 1.3

2. Current approaches

Open

User flow for creating on-the-block LTI 1.3 configuration

Open

User flow for using an existing configuration from LTI store

2.1 On-the-LTI Consumer XBlock configuration

An educator can configure an LTI tool directly in an LTI Consumer XBlock in Studio.

For LTI 1.1/1.2, credentials are stored in a course-level LTI passport. For LTI 1.3, Open edX creates an internal registration record and generates the platform keys and Client ID. Copying or duplicating an LTI 1.3 XBlock reuses that registration record.

Strengths:

1. It is built into Open edX and does not require any additional installation.

2. Educators can configure tools directly in Studio.

3. LTI 1.3 parameters are generated automatically upon Save.

4. Copied LTI 1.3 XBlocks share the same registration details. Each copy does not need to be registered separately with the tool.

Weaknesses:

1. From Studio, an LTI 1.3 registration is only accessible through one of its XBlocks. Losing the last usable XBlock can require registering the tool again unless the original can be recovered.

2. Reuse depends on finding and copying an existing XBlock.

3. Changes to one copy does not update the other copies.

4. There is no catalog of available configurations to choose from.

5. NRPS uses the XBlock location to identify the course, which does not work when the same configuration is used in multiple courses.

6. LTI 1.1 credentials use a separate passport string in course’s Advanced Settings. Authors with access to those settings can view the shared secret.

7. An LTI 1.1 copy only works in another course if the same passport also exists there.

2.2 LTI Store configuration

LTI Store is an optional plugin that stores LTI 1.1 and LTI 1.3 configurations independently from individual XBlocks. A site operator creates a configuration in Django Admin. An educator then enters its filter key in an LTI Consumer XBlock.

Strengths:

1. One independent LTI 1.1/1.3 configuration can be reused across unrelated courses and XBlocks.

2. Educators do not need to enter or view credentials.

3. Updates to a configuration apply to every XBlock that references it.

4. The configuration exists independently from any individual XBlock.

Weaknesses:

1. Operators must install and enable the plugin.

2. Configuration requires Django Admin access and normally has to be done by a site operator. There is no Studio interface for creating or managing configurations.

3. Current implementation does not generate Keyset URL and Access Token URL. The configuration has to be referenced in an LTI consumer XBlock, and XBlock has to be saved to obtain these values. So LTI store configuration is tightly coupled the placement i.e. LTI consumer XBlock.

4. Configurations have no course or organization scope and are effectively site-wide. Any course team can use a configuration if they know its filter key.

5. Educators cannot browse configurations. They must obtain and enter an opaque filter key.

6. LTI Store does not show which XBlocks reference a configuration.

7. Changing or deleting a configuration can affect multiple courses without a clear impact warning.

8. NRPS uses the XBlock location to identify the course, which does not work when the same configuration is used in multiple courses.

9. For LTI 1.3, an operator must generate and enter the platform private key.

2.3 What the comparison suggests

Direct XBlock configuration provides a Studio workflow and automatic LTI 1.3 credential generation. LTI Store provides an independent configuration that can be referenced by many XBlocks. Neither approach currently provides scoped availability, discovery, and a management UI for educators.

The desired state should preserve the useful parts of both approaches without requiring a configuration to be owned by a placement.

3. Goals for improvement

1. Configurations exist independently from where they are used (placements).

2. Authors can find and use configurations without handling credentials or internal identifiers.

3. Existing integrations continue working.

4. Configurations can support placement types beyond the LTI Consumer XBlock.

5. Configurations can support Dynamic registration in future.

4. Terminology

1. Configuration: A managed Open edX record containing the information needed to connect to and use an LTI tool.

2. Registration: For LTI 1.3, the security relationship between Open edX and the tool. The final relationship between a configuration and a registration remains a design decision.

3. Placement: One use of a configuration, such as an XBlock in course content or a link in course navigation. A placement contains settings specific to that use.

5. Proposed improvements

5.1 Make configuration independent from placement

The aim is for configurations to exist independently from the placements that use them. This should allow one configuration to be reused without being owned by an XBlock and should leave room for additional placement types in the future.

Connection, security, and tool-level settings should come from the configuration. Content, display, grading, and other usage-specific settings should remain with the placement.

The proposed allocation of existing fields is described in Appendix A.

Here’s what it requires, in addition to the capabilities currently provided by LTI store:

1. Generate 1.3 information without a placement: When an LTI 1.3 configuration or registration is created, Open edX should generate Client ID, Deployment ID, Access Token URL, Keyset URL and Login URL without requiring a placement (e.g. XBlock as of today).

2. Site-wide URLs: Access Token URL and Keyset URL should be site-wide rather than varying by configuration or placement. Other platforms that use site-wide platform endpoints:

   Open

   

3. Bind NRPS access to the course context: Today, the NRPS URL contains an LtiConfiguration ID https://{Open edX domain}/api/lti_consumer/v1/lti/{LtiConfiguration ID}/memberships, and Open edX derives the course from the configuration’s XBlock location. A reusable configuration may be used by many courses. The NRPS specification requires the context_memberships_url to be fully resolved and match the context of the launch (NRPS 2.0, §3.6.1.1). Therefore, the NRPS URL must identify both the reusable configuration and the course context. Before returning the roster, Open edX must check that NRPS is enabled for the configuration, the token belongs to the tool, and the tool is authorized to access that course. A configuration ID alone is not sufficient.

   1. Proposed way forward: Use an identifier representing the configuration’s association with the course. The endpoint would resolve the configuration and course from that identifier and perform the required authorization checks before returning the roster.

      Open

      

      The NRPS specification requires the context_memberships_url to be fully resolved and match the context of the launch.

5.2 Managing and using configurations in Studio

Studio should provide the author facing experience for managing and using reusable LTI configurations.

1. Create and manage configurations in Studio: Authorized users should be able to create, view, and edit LTI 1.1 and LTI 1.3 configurations in Studio.

   • For LTI 1.1, the key and secret should be managed as part of the configuration. New configurations should not require an LTI passport in the course’s Advanced Settings.

   • For LTI 1.3, Studio should show the generated information needed to complete registration with the tool.

2. Find and select a configuration: Authors should be able to browse or search the active configurations available to their course and select one by name. Studio should show enough information to distinguish between configurations. Authors should not need to enter an internal ID or filter key.

3. Name placements from the Deep Linking response: Studio should use lineItem.label as the placement’s default display name when present. If it is absent, Studio should use the title provided by user. Authors should be able to edit the name returned by deep linking.

   Open

   

   Deeplinking UX in Canvas
   Open

   

   Deep linking UX in Open edX

4. Distinguish configuration and placement settings: When editing a placement, Studio should distinguish values inherited from the configuration from settings belonging to that placement. Configuration values should be read-only unless Appendix A allows the placement to override them.

5.3 Configuration scope and permissions

A configuration’s scope determines which courses can find and use it. Permissions determine what a user can do with it. A configuration may be scoped to one or more courses, an organization, or the whole site.

1. Set a configuration’s scope: Authorized users should be able to set a configuration’s scope when creating or editing it. Users should only be able to choose scopes they are authorized to manage.

2. Use configurations within scope: A course team should be able to find and use configurations within its course’s scope. Scope alone should not grant permission to edit the configuration or view its credentials.

3. Protect credentials: Users who can use a configuration should be able to see the information needed to identify it, but not its key, secret, or private key unless they have permission to manage that configuration.

4. Handle scope changes safely: Reducing a configuration’s scope should show the affected courses and placements before the change is applied. The behaviour of existing placements must be defined before implementation.

5.3.1 Willow: use existing roles

Willow should use existing roles as a temporary solution, without introducing a new RBAC model.

• Course Staff can find and use configurations scoped to their course.

• Course Admins can create and manage configurations scoped to their course.

• Site administrators, using Django superuser access, can create and manage organization and site scoped configurations.

5.3.2 Xylon goal: configuration-specific permissions

Xylon should replace the temporary superuser fallback with a configuration-specific permission model. It should support appropriately scoped managers for course, organization, and site configurations, without granting broad Django superuser access.

The model should separately control who can create, use, view sensitive values, edit, change scope, deactivate, and delete a configuration.

5.4 Safe changes and lifecycle

A shared configuration may be used by placements in multiple courses. Studio should help users understand the effect of changes before they are applied.

1. Show usage and impact: Studio should show the courses and placements that reference a configuration. Before confirming a change that may affect placements, including changing a configuration-level setting, reducing its scope, or deactivating it, Studio should show the affected placements.

2. Apply shared changes consistently: Changing a configuration-level setting should update every placement that inherits that setting. Placement-specific overrides, where allowed in Appendix A, should remain unchanged.

3. Deactivate configurations: Authorized users should be able to deactivate a configuration instead of deleting it. A deactivated configuration should not be available for new placements and should prevent existing placements from launching the tool. Studio should show the affected placements before deactivation is confirmed. This will be required for Dynamic Registrations as well.

Open

Canvas: Warning when deactivating a configuration.

Open

Canvas: Deactivation is different from deleting a config.

Open

Canvas: Error msg when trying to launch a component whose LTI config has been deactivated.

5.5 Course rerun, import, and export

Course rerun, export, and import should have defined behavior for configuration references. It is yet to be defined.

When a course is exported, placements (e.g. XBlocks) should be exported with references to the configuration.

When a course is imported, if the configuration still exists, the placement should continue to reference it.

5.6 Transition

Existing directly configured XBlocks and LTI Store integrations should continue working during the transition.

New configurations should be created through the configuration management experience, and new placements should reference those configurations.

Appendix A

This appendix proposes how fields in the current LTI Consumer workflow should be divided between a reusable configuration and an individual placement. It responds to the “Which settings are reusable?” question in the technical proposal.

This broadly matches the current LTI Store implementation. LTI Store supplies reusable configuration values, while the LTI Consumer XBlock stores placement specific values.

The table covers existing LTI fields. A reusable configuration will also need metadata such as its name, description, scope etc.

When a field appears in both columns, the configuration provides the default and the placement may override it. A blank placement value inherits the configuration value.