1. LTI Configuration Reusability

An LTI integration is a relationship between Open edX and an external tool. For LTI 1.3, this relationship is established by registering information on both sides: Open edX registers information from the tool, and the tool registers information from Open edX.

Information needed to register platform/tool for LTI 1.3

Once this relationship is established, it should ideally be reusable across multiple LTI placements, and preferably at the course run, course, org, or site level like in Canvas.

Open edX is moving in this direction, but there are still gaps that need to be addressed.

Verawood improves XBlock duplication

In previous releases including Ulmo, LTI configuration is tightly coupled to the LTI XBlock that uses it. This creates friction when course teams want to reuse the same tool across multiple placements.

The Verawood release improves this by allowing duplicated and copied/pasted LTI XBlocks to inherit these 4 values, required by the tool, from the source XBlock:

Client ID
Deployment ID
Keyset URL
Access Token URL

This is an important improvement because these values need to be registered with the external tool during LTI 1.3 setup. If they change every time an XBlock is copied (which is the case in Ulmo), then each copied XBlock needs to be registered separately with the tool.

With Verawood, copying an LTI XBlock becomes more reusable and less likely to break the integration.

However, this is still different from reusable configuration management. XBlock duplication has the following limitations:

No discoverable reusable configuration: The 4 values mentioned above are created through XBlock duplication. They are not exposed as a reusable configuration that course teams can discover, manage, scope, or intentionally attach to new placements.
Copied XBlocks can drift apart: Changes to placement settings such as Launch URL, custom parameters, or other tool settings do not automatically propagate across copied XBlocks.

So while Verawood improves the copy/paste workflow, it does not fully solve LTI configuration reuse.

LTI Store is closer to reusable configuration

The LTI Store plugin allows one saved LTI configuration to be referenced by multiple LTI XBlocks.

This is a better foundation for reuse than copying XBlocks because the configuration exists independently from any individual placement.

However, the LTI Store also has limitations today:

No configuration scopes: LTI Store configurations are not scoped. A saved configuration is currently available site-wide, which is a concern for governance and security. Any author for any course or org can use a saved configuration if they know the config ID.
Limited access: LTI Store is managed through Django admin panel, which is typically limited to site operators. This means course teams usually cannot create or manage reusable LTI configurations themselves.

The remaining gap is that Open edX still needs a way for LTI configurations to be reusable, manageable, appropriately scoped, and usable by the right course or platform roles without unnecessary operator involvement.

The goal is not only to make copied XBlocks work better. The broader goal is to make LTI configuration reuse easier to manage as courses, tools, organizations, and platform deployments scale.

2. Permissions, RBAC and LTI config admin panel

3. Dynamic registration

4. Improve PII sharing logic

PII sharing logic in LTI consumer XBlock is complex and is likely difficult to understand by course teams. Here's what currently exists:

Tool launch: PII is only shared if the user provides consent before the launch, irrespective of the waffle flag.
Deep linking launch: PII sharing depends on Request user's username/email/name setting in XBlock config. User consent is NOT collected. Also this is independent of waffle flag.
NRPS: In response to NRPS read call, PII sharing only depends on the waffle flag and is independent of XBlock configs. User consent is NOT collected.

We need to improve consistency and clarity in PII sharing.

5. Add validations in XBlock and LTI store

Today, if a user enters invalid information e.g. incorrect format of custom parameters, in the LTI XBlock or LTI Store configuration, the form simply fails to save without explaining why.

We need to add validation and user-facing error messages to LTI configuration forms in both:

LTI Consumer XBlock configuration
LTI Store configuration UI (when built in Studio)

6. Masquarde tool with LTI

7. Course level integrations via LTI store

If we can modify LTI store to generate Access Token URL and Public Keyset URL independent of LTI consumer XBlock, we can use these configurations to render LTI tools at the course level.

Open edX already has the capability to render 4 discussion tools and 2 video conferencing tools in the course navigation. But its limited to 6 tools and it uses LTI 1.1.

This course-level rendering will likely not support grading.

Ignore everything below this line.

Open questions for 1

What configuration scopes should be supported: course run, course, org, site, or some subset of these?
Which roles should be able to create, edit, delete, and use LTI configurations at each scope?
Which values should live on a reusable configuration, and which should remain placement-specific on the XBlock?
How should Open edX show the impact of editing a reusable configuration that is already used by many placements?
What configuration scopes should be supported: course run, course, org, site, or some subset of these?
Which roles should be able to create, edit, delete, and use LTI configurations at each scope?
Which values should live on a reusable configuration, and which should remain placement-specific on the XBlock?
How should Open edX show the impact of editing a reusable configuration that is already used by many placements?

LTI improvements [for Willow & beyond]