Preliminary Discovery: LTI Directory

[e0d]

tCRIL is undertaking preliminary discovery work to understand key questions about an LTI Catalog/Directory:

• [x] What related projects might be underway in the community?

Ease of use/integration of third-party LTI apps is contingent on being able to configure apps globally. This project is already underway to enable global config: https://github.com/openedx/platform-roadmap/issues/143

• [x] What is the competitive landscape for LTI integration workflows?

Other LMS workflows and high-level brainstorm design doc: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/3471409186/Design+Exploration+End-to-end+workflows

• [x] Write user stories

Investigate what users want from an LTI catalog? User stories for an LTI catalog and point-and-click workflows: https://docs.google.com/spreadsheets/d/1-SKV33_IdzNxESTTIQeerlN6FyGeqXgLE3tqebsxOGk/edit#gid=1059845418

[e0d]

@marcotuts was this a placeholder for what Gabriel mentioned?

[jmakowski1123]

@marcotuts was this a placeholder for what Gabriel mentioned?

I believe the OC project is focused on removing the dependencies from xblock for LTI 1.3 launches - this will allow LTI 1.3 to launch from anywhere in the platform. https://github.com/openedx/platform-roadmap/issues/143

That's part of the puzzle. I'd like to cast a wider net in terms of discovery that incorporates a full view of catalog/directory options/approaches and an end-to-end author and dev workflow(s).

[Kelketek]

I believe the OC project is focused on removing the dependencies from xblock for LTI 1.3 launches - this will allow LTI 1.3 to launch from anywhere in the platform. #143

That is a separate project, yes, but we were (and are!) also quite interested in helping with this one. Marco had brought up the need for an LTI/plugin directory at the conference, which is what Gabriel was reaching out about. :)

[ormsbee]

When it comes to LTI configuration re-use, I have a bunch of questions around lifecycle, ownership, and authorization. I absolutely agree that centralized management is a good idea and will provide a vastly superior user experience, but I also think that there’s a bunch of complexity lurking behind this feature.

At the very base layer, we’d have the content from the IMS spec on LTI launch XML description files (example) — things like the launch URL, custom parameters, etc. But then we have things like consumer key and secret (platform-wide? per-org? per-course? across multiple courses controlled by the same group on different instances?). We also have PII policy. And the thing that most often gets overlooked: import/export behavior (both within the same instance and across instances).

So I’m curious where these layers are in this centralized configuration. Is there some base set of LTI config templates available, and it gets copied into the Learning Context (i.e. Course Run) when you add things like the consumer key/secret? How are re-runs handled? Import/export across instances? Are configurations ever shared across courses, and can they be edited outside of the normal Studio edit/publish cycle?

[ormsbee]

@Zacharis278: @schenedx suggested that I should tag you on this and the related initiative ticket around centralized LTI configuration management, as it might overlap some of the stuff that you're already looking into with respect to LTI proctoring. I'd love to get your thoughts on the subject when you have a moment. 😄

[Zacharis278]

@ormsbee

To give context on the proctoring side of things. For proctoring the focus has been on platform-wide configuration for the initial delivery. That allows us to skirt a lot of these issues since no LTI details get copied into or come from the learning context. We're actually not changing much in the studio/authoring side. Previously a course had a "proctoring provider" key that pointed to a pile of environment variables, now that just points to a platform-wide LTIConfiguration. Future state, we would like to allow course teams to set up their own LTI configuration. Although, I can't say I've thought of this too much beyond keeping it as a design consideration.

I have not given too much thought into sharing reusable configurations yet so I'm mostly thinking up more questions than answers here. There's definitely some different types of use cases. Is the tool we're launching part of the course content (traditional xblock-consumer) or is it some platform capability (discussions/live/proctoring)? The latter seems a lot easier to have broadly shared configuration for since this can be done outside of studio and credentials don't necessarily need to be exposed. It seems to me an xblock launch as part of the course content is going to necessitate that any shared configuration details/credentials be exposed if we want export/import to fully function.

A pattern that could actually help with this is being established in https://github.com/openedx/xblock-lti-consumer/pull/254 where the database is the source of truth for loading configuration but we also keep the xblock in sync. Maybe we could do something similar for shared configuration where only non-sensitive configuration values are visible from the outside and/or copied down into the course content itself?

I guess to get we could maintain reusable but incomplete base configurations but I'm fuzzy on how valuable it would be. If the course team has to get a consumer key and secret I presume they have the launch URL and other details anyway right?

Throwing ideas into the wind here but sounds like this feature needs its own access control mechanism that would know what courses are allowed to use what configurations? What courses are able to copy the secret values of a configuration? etc.

This could definitely be a helpful feature as we make more use of LTI. Happy to chat more about it