Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

LTI 2 support: Difference between revisions

From MoodleDocs
(Initial project description)
Line 69: Line 69:


==Database changes==
==Database changes==
Coming soon!
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
 
===lti_tool_proxies table===
{| class="nicetable"
|-
! Field name
! Type
! Description
|-
| id
| int(10)
| Primary key
|-
| regurl
| text
| Registration URL
|-
| state
| tinyint(2)
| Current state of tool proxy processing
|-
| guid
| varchar(255)
| Consumer key
|-
| secret
| varchar(255)
| Shared secret
|-
| 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
|}
 
===lti_types table===
{| class="nicetable"
|-
! Field name
! Type
! Description
|-
| 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
|}
 
===lti_tool_settings===
{| class="nicetable"
|-
! Field name
! Type
! Description
|-
| id
| int(10)
| Primary key
|-
| 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)
|-
| name
| varchar(255)
| Setting name
|-
| value
| varchar(255)
| Setting value
|}

Revision as of 03:05, 4 June 2014

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.

LTI 2 support
Project state Planning
Tracker issue NA
Discussion NA
Assignee Stephen Vickers


Project goals

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.

Background

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.

Introduction

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):

  1. MDL-28946: Add support for multi-tenancy sites
  2. MDL-37041: The LTI consumer does not pass the user's profile picture in the user_image launch parameter
  3. MDL-37445: Add ability to set Maximum Grade for External Tool
  4. MDL-38120: course reports for external tool misssing
  5. MDL-41202: LTI course identifier is not configurable; relies on shortname exclusively
  6. MDL-41724: Implement the IMS LTI contexts membership service
  7. MDL-45064: Option to add LTI Tool to Activity Chooser
  8. Visibility of external tools in the activity choose
  9. Support for both activity and resource types
  10. passing the Username?
  11. More flexibility with passing appropriate roles
  12. 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)

  1. 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)
  2. Add a new link labelled something like "Register new external tool" which can be used to initiate the tool registration process

See also "Registration process" section below.

Register new external tool page (new)

  1. New page allowing the following data entry:
    1. registration URL
    2. select capabilities to be offered to the tool provider
    3. select services to be made available for use by the tool provider
    4. link/button to initiate the registration process; link/button 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.

Registration process

Once initiated a Tool Proxy registration will have one of the following states:

  1. created
  2. in process
  3. completed
  4. rejected
  5. cancelled

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).

Managing tools

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.

Database changes

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

lti_tool_proxies table

Field name Type Description
id int(10) Primary key
regurl text Registration URL
state tinyint(2) Current state of tool proxy processing
guid varchar(255) Consumer key
secret varchar(255) Shared secret
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

lti_types table

Field name Type Description
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

lti_tool_settings

Field name Type Description
id int(10) Primary key
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)
name varchar(255) Setting name
value varchar(255) Setting value