LTI 1.3 support
| LTI 1.3 for Moodle Tool Provider | |
|---|---|
| Project state | Planning |
| Tracker issue | MDL-64780 |
| Discussion | LTI 1.3 for Moodle Tool Provider |
| Assignee | Stephen Vickers |
Project goals
Work is underway to add LTI 1.3 support for Moodle as a Tool Consumer (see MDL-62599). This project seeks to make similar updates for the LTI Tool Provider functionality in Moodle.
Introduction
LTI 1.3 introduces a new security framework to LTI messages and service requests. Rather than using the OAuth 1.0A message signing specification, it uses JWTs signed with asymmetric keys and OAuth 2 bearer tokens to provide access to services. It also uses an OpenID Connect flow to initiate messages. This means that any integration between a tool consumer (now referred to as a platform) and a tool provider (now referred to as a tool) requires different configuration data to be agreed between the two parties (a launch URL, consumer key and secret are no longer sufficient).
IMS uses the term "LTI Advantage" to refer to systems which implement LTI 1.3 alongside the Deep Linking message (fka Content-Item message), the Names and Role Provisioning services (fka Membership service) and the Assignment and Grade services. These need to be considered in addition to merely supporting the new security model.
User interface changes
A new LTI tool is created with
/enrol/editinstance.php
. This page must be updated to:
- allow the LTI version to be selected (1.0/1.1, 1.3 or 2.0)
- when LTI 1.3 is selected the secret field is hidden and additional input fields revealed for entering data provided by the Platform:
- client ID
- platform ID
- Authentication request URL
- Access Token service URL
- Tool Consumer Public keys URL
- when LTI 2.0 is selected the secret field is hidden
Details of existing tool definitions are viewed with
/enrol/lti/index.php?courseid=x
. This page must be updated to:
- display the details according to the LTI version selected
- for LTI 1.0/1.1 these details would be:
- Launch URL
- Secret
- Cartridge XML URL
- for LTI 1.3 these details would be:
- initiate login URL
- redirection URL
- public key
- for LTI 2.0 these details would be:
- Registration URL
- for LTI 1.0/1.1 these details would be:
Code changes
- The third-party LTI Tool Provider library needs to be updated to one which supports LTI 1.3 and all references to the classes updated accordingly.
- New code to support the OpenID Connect workflow
- The changes introduced with the new security model should be handled by the LTI class library
Issues with existing implementation
The present implementation offers a relaxed approach to connecting a tool with a Platform:
- each tool can be connected using either LTI 1.0/1.1 or LTI 2.0 at the choice of the platform
- for LTI 1.0/1.1 connections the Platform is left to select the consumer key
- each tool can be accessed from multiple Platforms provided each uses a different consumer key
- all LTI 1.0/1.1 connections to a tool will use the same secret
The issues I see with this are:
- all Platforms using the same secret is not very secure
- allowing Platforms to select the consumer key could lead to clashes - the database requires all consumer keys to be unique
- allowing multiple Platforms to use the same tool definition makes it difficult to manage access (e.g. disable) for a single Platform without impacting the others
A proposed change would be for Moodle to generate the LTI 1.0/1.1 consumer key and to limit access to only this key/secret combination - to allow access by other Platforms would require additional tools to be defined (one tool definition per Platform). This would make it consistent with the LTI 1.3 approach which expects the Platform to supply the Client ID etc. to the Tool out-of-band. (LTI 2.0 registrations would also be limited to one per tool.)
In atddition, the list of activities/resources which can be made available as LTI tools includes LTI links themselves - such chaining of LTI connections is not (yet) supported in the spec. A proposed change is that this list should exclude LTI links and only include native Moodle activities/resources.
New functionality
The Assignment and Grade services allow a Tool to manage line-items in a Platform's gradebook. This means that a Tool can pass back to a Platform more than one grade per user per resource link. If such functionality is desired then some mechanism will be needed to allow a teacher to select which gradebook columns should be passed back to the Platform (I don't think leaving a Tool to pass back all the gradebook columns is appropriate, there should be some way of limiting them).
