A Practical Overview of LTI

A Practical Overview of LTI v1.1

Learning Tools Interoperability (LTI) is a standard developed by IMS Global to facilitate integration of learning tools with learning management systems.  At its essence, LTI is a security protocol, built on top of OAuth that provides a method for a secure trusted launch of a learning tool sharing some course and user information from the LMS to the tool.  This post will the basics of working with LTI, as well as explore some practical considerations that arise in various use cases.

Getting Started

At the core of LTI is the consumer key and secret.  These act like a username and password, and are typically agreed on by the LMS and tool via phone, email, or other such process.  When the tool is set up in the LMS, the administrator or teacher will provide the key, secret, and launch URL.  When launched, the LMS sends a POST request to the launch URL containing a number of parameters, including the consumer key and a signature created by OAuth using the parameters and the secret.  When the tool receives the POST, it can use OAuth to verify the signature using the secret, thereby ensuring the parameters were not tampered with or sent from someone not knowing the secret.

The actual process of doing the signatures is laid out well in sample code for several common languages provided by IMS on Google code.

In the POST, the consumer key is sent as oauth_consumer_key

Use Case 1:  LTI as a glorified link

If a tool did not actually need any data from the consumer, and the LTI link is really acting like a glorified link, the tool could completely ignore the key, secret, and POST parameters altogether.

Use Case 2:  Course Level connection

A tool like Tegrity might want to list all the Tegrity recordings for a specific course when launched.  For that, they need to link the LMS course with their local course identifier.  This is done through the launch parameter context_id, which provides a unique identifier from the LMS for the course section.  This parameter is recommended, not required, but is usually sent.  This is often used in combination with context_title, a description or title for the course, and/or context_label, which is a short label or name for the course (like MA151).

To determine if the user should having editing rights, the tool can look at the parameter roles, which provides a list of roles for the user.  Consult the specs or sample code for how to make sense of this field.

If the tool needs to connect LMS users with user accounts on the tool, then the parameter user_id can be used.  Name can sometimes be obtained from lis_person_name_given, lis_person_name_family, and/or lis_person_name_full.   Be aware some LMSs send none of this information depending on link configuration.

Tool Workflow:

• Use oauth_consumer_key and context_id to look up the course in local DB
  • If found, direct the user into the connected tool resource
  • If not found, create a tool resource, and record the connection in local DB
  • If user accounts are need:  Use oauth_consumer_key and user_id to look up user in local DB
    • If found, login that user
    • If not found, create a new user account, record in local DB, and login that user

Use Case 3:  Ephemeral links

In the previous case, there would normally be only one link from the LMS to the tool.  Some tools, like Etherpad, are intended to be used multiple times in a course, with each link taking the user to a separate Etherpad document.  In this case, there is typically no need or desire for the links to persist (point to the same document) if the course on the LMS is copied.  For this purpose, the resource_link_id parameter can be use.  This ID is unique for each placement of the tool in a course, so can be used to connect an LMS link with a unique item on the tool.

Tool Workflow:

• Use oauth_consumer_key and resource_link_id to look up link placement in local DB
  • If found, direct user to the appropriate tool page
  • If not found:
    • If the tool is something like Etherpad, where a new link should point to a new blank resource
      • Create a new blank resource, record the connection in local DB
      • Direct user to blank resource
      • If the tool is something like a content reader, with a set of content items that can be linked to
        • Provide a GUI for a user (with instructor role) to select a content item from a list.
        • On selection, record the connection in local DB
        • Direct user to that resource

Use Case 4:  Persistent content links

A tool like a textbook reader, assessment system, or learning object repository may wish to set up links in the LMS which point to a content item on the tool, for which those links will continue to point to the same item if the course on the LMS is copied.  There are two ways to do this, though the specific approach that can be used depends on the LMS.

Approach 1:  Use query strings on the launch URL to indicate the content item.  This approach works in Canvas, Moodle, Desire2Learn, and BlackBoard (see caveat below). 

Approach 2:  Use custom parameters.  These get sent with POST parameters as custom_{name}.  This approach works in BlackBoard (again, see caveat below).  I’m not sure about D2L and Moodle, but it does not work in Canvas.

BlackBoard caveat:  Bb only allows custom parameters or link-specific URLs to be specified when using the “this link is to a Tool Provider” option for web links, and only when the credentials are set up by the instructor.  When a system-wide tool is set up, the options to specify the link or custom parameters is hidden.  Likewise, if a tool is set up using Bb’s tool provider and tool placement mechanism (which adds the tool to the content building menus), URL and custom fields cannot be specified.  This makes it essentially impossible to have a system-wide tool and have persistent content-specific links.

Canvas addendum:  Canvas has an LTI extension called content selection.  Using this, the instructor creates a new LTI tool placement, the tool is called and provides a way for the instructor to select a content item.  The tool then returns a unique URL to Canvas which gets stored as the launch URL.  This provides a way to have a GUI for setting up persistent content links.

Tool Workflow:  (not including Canvas extension)

• If the tool wants to provide a user-customizable version of the indicated resource, on first launch the tool could make a copy of the indicated resource, and record an ephemeral link placement (with the downside that the customized version will not be retained on an LMS course copy) or some other approach
• Direct user to the indicated resource

Use Case 5:  Grade return

Tools that deliver assessments may want to return a score to the LMS.  The LMS will indicate it’s willing to accept a score by sending lis_result_sourcedid, which is a unique identifier that the LMS can use to determine both the user and link, and lis_outcome_service_url, a URL the tool uses for sending back the score to the LMS.  The details of the format can be pulled from the spec or sample code.

In Canvas, tool placements are only gradable if they are set up as Assignments and a point value is assigned.

In Blackboard, unfortunately if web links are used for tool launches and the tool credentials are set up system-wide, there is no way for an instructor to indicate that a link is gradable, which is frustrating for tools that need persistent content links.

I have not had a chance to test grade return setup in D2L or Moodle.

Tool Workflow:

• Record the lis_result_sourcedid and lis_outcome_service_url when the link is launched in local DB, associated with tool resource and user.
• When the grade needs to be updated, use those fields to return the grade to the LMS

Use Case 6:  Lots of content links

A content reader might want to provide an LTI link for each chapter of the text, or an assessment system might want to set up links for each assignment.  For a teacher to have to create these would be very time consuming and difficult if a list of unique URLs have to essentially be copy-pasted in.

To address this, the Common Cartridge format provides a means for importing LTI links.  The details are beyond what I’m going to go into here, but I will address some of the challenges.

In Canvas, this process works well, though if a system-wide key and secret have already been set up, the instructor will have to delete the tool created during the import process.  Canvas has added extensions to the specs that allow the common cartridge to indicate if an item is intended to be gradable and the points possible.

In Blackboard, this process works fine.  The LTI links come in as web links with the “this link is to a tool provider” option.  Unfortunately, as above, if the tool credentials are set up system-wide, there is no way for an instructor to indicate that a link is gradable.  Even if the tool credentials are set up in the course, there is no way to indicate in the cartridge that the item is gradable or the points possible, so the instructor still will need to manually make those changes for every link.

In Desire2Learn, this process does not appear to work at all.

In Moodle, this process worked when I tried it in Moodle 1.9.  I haven’t tried it in Moodle 2.x yet, nor have I explored the grade return setup.