LTI 2 support
|LTI 2 support|
|Discussion||Adding LTI 2.0 support|
- 1 Project goals
- 2 Background
- 3 Introduction
- 4 Current issues with existing LTI functionality
- 5 User interface changes
- 6 Database changes
- 7 Defining services
- 8 Tasks
The main goal of this project is to implement LTI 2.0 functionality for Moodle which is capable of passing the IMS certification tests. It is not expected that the required changes will have any significant impact on the current LTI 1.1 functionality; indeed it is hoped that the work will also have some beneficial side-effects for the current LTI implementation.
Vital Source Technologies recognises the benefits that the IMS Learning Tools Interoperability (LTI) 2 specification can deliver to tool providers and has, therefore, agreed to sponsor this project in the interests of the whole community. The work will be undertaken in collaboration with Moodlerooms as an adaptation of the existing LTI (External tool) module which they manage on behalf of the Moodle community.
Moodle already provides support for LTI 1.1, this project will build on this support to add support for LTI 2.0; it will not remove any existing functionality but it is expected that the LTI 1 support will also be enhanced as a consequence of this work. The main differences between LTI 1.1 and LTI 2.0 are as follows:
- Tool registration
- Rather than passing a launch URL, consumer key and shared secret from the tool provider to the tool consumer using some out-of-band communication, LTI 2 uses an interactive registration process; all a tool consumer administrator needs is the URL for initiating this process.
- Tool Consumer Profile
- as part of the registration process, a tool consumer makes available to the tool provider a profile describing itself and the capabilities/services it is willing to make available.
- Tool Proxy
- when "sealing the deal" between the two parties, the tool provider sends a Tool Proxy to the tool consumer which includes a profile about itself and details of the capabilities/services which it proposes to use. A tool Proxy can be used to register more than one tool (resource handler), all of which are secured using the consumer key and shared secret agreed by the two systems during this process.
- Launch process
- whilst the mechanics of launching an LTI tool remain unchanged from LTI 1, the tool proxy allows the data passed on launch to be tailored to specific requirements. The custom parameter substitution variables (available in LTI 1 but not implemented in the current Moodle implementation) are used to enable this functionality.
- Tool Settings service
- LTI 2.0 includes a service which allows a tool provider to request a tool consumer to record data (name and value pairs) which are passed back on each launch. Settings may be saved at one of three levels: system-wide (Tool Proxy level), context-wide (Tool Proxy binding level, e.g. course-wide) and resource specific (LTI link level, i.e. specific to an individual link added to a course). This service is helpful as it ensures settings are deleted when a link or course is deleted, and it can also help when a course containing links to a tool provider is copied.
- Discoverable services
- the addition of the tool consumer and tool profiles allows each party to declare services which it is willing to offer the other party. These services may be ones included in the IMS LTI specification (e.g. Tool Settings), but may equally be ones written by other parties which have yet to become part of the specification (and perhaps never will). Provided both the tool consumer and tool provider have implemented the service, the trust relationship established using LTI can be leveraged to secure the request messages between the servers. This transforms an LTI tool consumer into an extensible platform for learning tools and resources.
Current issues with existing LTI functionality
There are a number of open Moodle Tracker items relating to enhancements to the LTI implementation. Whilst this project is not directly concerned with resolving these issues, it does provide an opportunity to review them and see how they might guide the decisions being taken so they are consistent and may indeed provide solutions as a byproduct. Here is a list of those identified so far (some are from discussion postings or other sources):
- Add support for multi-tenancy sites to permit different LTI credentials for courses in different sites
- MDL-37041: The LTI consumer does not pass the user's profile picture in the user_image launch parameter
- MDL-37445: Add ability to set Maximum Grade for External Tool
- MDL-38120: course reports for external tool misssing
- MDL-39134: Create an LTI filter
- MDL-41202: LTI course identifier is not configurable; relies on shortname exclusively
- MDL-41724 (Fixed, as of Moodle 3.0): Implement the IMS LTI contexts membership service
- MDL-45064 (Fixed, as of Moodle 3.1): Option to add LTI Tool to Activity Chooser
- Visibility of external tools in the activity choose
- Support for both activity and resource types
- passing the Username?
- More flexibility with passing appropriate roles
- Support for success and log messages on return URL
If you know of any missing from this list then please add a comment or get in touch; no promises that it will get included!
User interface changes
It is anticipated that the LTI 2 functionality can be added on top of the existing LTI 1.1 support with minimal impact on the current user interface. This section describes the current proposals for the new registration workflows.
Plugin settings page (existing)
- Move the "Add external tool configuration" link outside the "Active" tab and place below the tool list (may need to go above to save scrolling when the list of tools is long)
- Add a new link labelled something like "Register new external tool" which can be used to initiate the tool registration process
- Add a new tab set to list enabled and disabled services with icon to toggle their current status (by default a new service would be disabled)
See also "Registration process" section below.
Register new external tool page (new)
New page allowing the following data entry:
- registration URL
- simple text box
- select capabilities to be offered to the tool provider
- textarea of selected capabilities, textarea of potential capabilities, buttons to add and remove capabilities from selection
- select services to be made available for use by the tool provider
- textarea of selected services, textarea of potential services, buttons to add and remove services from selection
- option to initiate the registration process
- option to cancel the process
Initiating the registration would generate a random key and secret and redirect the administrator to the tool provider using a ToolProxyRegistrationRequest message. The next part of the process is dependent upon the implementation by the tool provider based on their business rules. It would, however, depend upon the provision of a Tool Consumer Profile service; the profile provided would be based on the capabilities and services selected on this page (i.e. would be specific to a registration request). On completion the tool provider will call the Tool Proxy service.
Once initiated a Tool Proxy registration will have one of the following states:
- in process
A rejected or cancelled registration would be logged but not remain visible in the UI. A new tab would be required on the Plugin settings page for any "in process" registrations (initiated but not yet completed by the creation of a tool proxy). An icon would be included next to each link to cancel a registration. A completed registration will generate a tool proxy associated with each of the tools (resource handlers) it specifies (which would be added to the "Pending" tab on the Plugin settings page).
Once a Tool Proxy has been accepted its resource handlers will be added as if they were external tools created manually using the current LTI 1 process. Their initial state will be pending; an administrator must enable them to make them available. They will appear to instructors (and learners) just like an LTI 1 external tool - there is no need for them to see any difference. The only difference will be behind the scenes when a launch request is made, the launch parameters will be determined on the basis of the resource handler definition from the tool proxy rather than being a generic LTI 1 launch. Support would also be added for custom parameter substitution variables which could/would also be available to LTI 1 launches.
It is anticipated that the addition of LTI 2 support will require the following database changes:
- new table to capture details of tool proxies
- new fields to lti_types table to record:
- foreign key for tool proxy
- enabled capabilities
- launch parameters
- icon and secureicon URLs
- new table to record tool settings
|state||tinyint(2)||Current state of tool proxy processing|
|capabilityoffered||text||Capabilities offered to Tool Provider|
|serviceoffered||text||Services offered to Tool Provider|
|toolproxy||text||Copy of agreed Tool Proxy (JSON)|
|createdby||int(10)||ID of user which initiated the registration process|
|timecreated||int(10)||Date/time at which the record was created|
|timemodified||int(10)||Date/time at which the record was last modified|
|toolproxyid||int(10)||Primary key of related tool proxy (null for LTI 1 tools)|
|enabledcapability||text||Enabled capabilities (null for LTI 1 tools)|
|parameter||text||Launch parameters (null for LTI 1 tools)|
|icon||text||URL to icon file|
|secureicon||text||Secure URL to icon file|
|toolproxyid||int(10)||Primary key of related tool proxy|
|course||int(10)||Primary key of course (null for system-wide settings)|
|coursemoduleid||int(10)||Primary key of course module - tool link added to course (null for system-wide and context-wide settings)|
The goal is to enable the list of available services to be extensible, this includes the Tool Consumer Profile, Tool Proxy and Tool Settings services which are required elements of LTI 2.0. A service is an endpoint to which requests may be sent; these requests send or receive resources of a specified media type.
- ID - unique ID for service
- Name - a display name for service
- IsEnabled - whether the service is currently enabled
- Resources - list of media types associated with the service
- Endpoint - URL for service requests
- ParseValue - parse a custom parameter value for substitution variables defined by the service and/or its resources
- CheckSignature - check the OAuth signature for a request received
- ID - unique ID for resource
- Template - URL template for service requests
- Media types - list of supported media types
- Methods - supported HTTP methods
- Capabilities - names of available capabilities
- Parameters - values of parameters included in request template
- Endpoint - fully qualified URL
- ParseValue - parse a custom parameter value for substitution variables defined by the resource
The initial approach will be to try to implement the above requirements using the existing LTI Source Plugins functionality.
- registration page
- defining services
- tool consumer profile service
- tool proxy service
- tool settings service
- enable/disable tools
- generate launch request (including custom parameter substitution variables)