LTI2 Introduction

By John Tibbetts, Integration Architect, Vital Source Technologies

Learning Tools Interoperability (LTI) version 2 is the latest step in the evolution of this highly popular standard and its single, most dramatic, upgrade in its history.  This article introduces LTI 2 by examining the characteristics of its predecessor versions and calling out the forces that has led to its redesign.

LTI v1.0: Beginnings

LTI 1.0 was a success almost from the moment of inception for several simple reasons:

• Its mission was crystal-clear: to allow a learning system, particularly a Learning Management System (LMS), to launch an external learning tool and run it as if it were an integrated part of the learning system.
• To perform this launch with sufficient security that it protected the learning tool from misuse.
• It took the simplest approach possible to achieve these goals.
• It benefited from strong early advocacy, especially from the tireless promotion of Dr. Chuck Severance.

The key to understanding LTI 1.0 is to realize that it focuses on one, and only one, aspect of tool interoperability, the tool’s launch.

User Story

A very common user story for LTI is the opening of an e-textbook from within the LMS.  This is such a widely used case it’s often been called the ‘killer app’ of LTI.

A student logs into her LMS, proceeds to her math course, and finds that her instructor has placed a link to a calculus text.  She clicks on the link and the book opens to chapter 3; to the very page of the next assigned reading.  She then reads, advances through other pages, jumps to references, leaves notes, etc.  

Architecture

Schematically the LTI 1.0 launch looks like this:

1. A user, perhaps a student, clicks on an LTI link that requests a tool launch.
2. The learning system (labeled Tool Consumer, or TC) prepares a bundle of launch parameters including standard, optional, and custom parameters that are part of the ‘envelope’ of the launch message.
3. OAuth digitally signs the payload to ensure its integrity.
4. The TC then sends this message back to the browser and a tiny piece of javascript auto-POSTs the message to the Tool Provider.
5. The Tool Provider responds with a presentation of the tool in the browser.

The peculiar piece of orchestration (step 4) is essential to the LTI launch; it ensures that the source of the launch is the user (actually the browser, the user’s agent) rather than the TC server.

LTI 1.0 is solely about tool launch.  Think of it as being like a cannon firing a cannon ball:

Ignoring air resistance, everything about the targeting of the cannonball is pre-determined at the moment the ball leaves the muzzle of the cannon.  Likewise everything about the textbook appearance, its size, position, its page, is determined by the bundle of parameters contained in the launch.

We’ll use this metaphor again as we examine successor versions.

LTI v1.1:  Course Correction

After LTI 1.0 established itself as the premier interoperability standard, a particular need arose that caused a change to its specification.  Some learning tools return a grade from the tool that the tool would like to pass back into the LMS gradebook. Since LTI 1.0 lost contact between TC and TP after launch (cannonball past the muzzle) another communication channel was required to get a tool outcome back from the launch and redirected to the gradebook.

User Story

At week’s end, our calculus student is ready to take a weekly assessment.  She presses the link and it now directs her to an exercise within the book (or possibly in a separate standalone assessment tool).  She takes the exercise, feels good about the results, and submits the result.  When she goes over to her LMS gradebook she sees the grade she’s accrued.

Architecture

The LTI 1.1 diagram is shown next:

1. The launch phase is structurally identical to a LTI 1.0 launch.  (The dotted line is a shorthand for the multiple arrows in the 1.0 launch).
2. However at least two extra parameters are passed in the launch:

1. lis_outcome_service_url is a return point to which an outcome may be placed into the gradebook
2. lis_result_sourcedid is an encrypted ticket provided by the LMS to ensure that the outcome is properly labeled for the particular user, course, and link that are involved in this interaction

It’s not obvious from the diagram, but the message with the returned outcome is completely asynchronous from the launch.  That is, anytime after the launch, whether seconds or weeks, it can return the outcome to the gradebook.

LTI v1.2: Preview

(Explanation coming at the bottom of this document)

LTI 1.2 was co-developed with LTI 2.0.  It is a subset of LTI 2.0 that some LTI 1.0 vendors may use it as a steppingstone to LTI 2.0.  It will be easier to explain after LTI 2.0 is presented.  

LTI v2.0: Learning Tools (with full) Interoperability

LTI 2.0 is a major rewrite of LTI 1.  It is designed to extend interoperability to the entire lifecycle of the tool not just to the launch point.  This change is so profound that it enables LTI 2.0 to be a platform not just for embedding a tool but also for creating:

• very smart, adaptive tools
• or even general-purpose educational web applications

User Story

The e-textbook vendors became aware very early on that LTI was an ideal vehicle to easily open books within an LMS.  Furthermore they could perform this integration in minutes rather than weeks.

However the next challenge became provisioning the books in the LMS so that the right books would be available to the right courses.  A school might have hundreds of courses each of which might adopt several books.  Furthermore some schools would adopt course-book pairs by mandate and others encouraged individual professors to make their own choices.  Provisioning thousands of links in a school using custom LTI parameters was a non-starter.  A best practice of creating book adoption applications evolved but required lots of proprietary web services.  

LTI 2 (and LTI 1.2, see below) can fix this situation by supporting an LTI-launched application that is a book adoption application.  It supports the following:

• Instructors browsing a book catalog and selecting books
• The selected books are stored with the LMS course using a ToolSettings service
• Certain billing models might require invoking a Roster service in the institution to get a census of students to determine billing

Architecture

The LTI 1-style launch is still essentially the same and shown as the dotted line but there are a couple of new interaction types.

The major deliverable in LTI 2 is standardized, architected, REST services that implemented using industry best-practice.  Much more on these services and on the Registration phase is presented below.

REST-level 3 Web Service Model

REST web services are the preferred technique in usage today for implementing distributed services within web applications.  As often happens, the term is pretty sloppily used.  On the other hand, LTI has used a precise recipe for REST services based on the Richardson Maturity Model.  

Level 3 REST requires:

1. Resources as basis for HTTP addressing
2. Proper use of HTTP intrinsic methods
3. Media type definitions supporting Linked Data

JSON-LD for Payload Definition

JSON is widely used because it is lightweight and simple to use.  The Linked Data (LD) extensions provide hypermedia linking between media types.

Discoverable Services

Most web service applications have stable interface contract definitions because both consumers and suppliers have a general agreement of what their capabilities and constraints are and what services each partner offers.   But educational partners are more loosely coupled.  Consider a few sample characteristics:

• A learning institution might not want to share its roster to all or any of its tool providers
• Some tools may offer returned outcomes, some may not, finally others may offer them as an option.
• Some institutions may not be able to share student email addresses, yet some tool providers may require it.

In any particular pairing of tool consumer and tool provider a specific interface contract needs to be struck and recorded.  This contract is called a Tool Proxy.  It is shown in a diagram below:

The Tool Proxy is negotiated by the two parties (TC and TP) automatically but allows human workflows on either side to intervene if necessary.

This negotiation is performed during the Registration phase shown in the LTI 2 Architecture diagram above.

Automatic Credential Exchange and Management

The Registration phase also bakes the LTI key and secret into the Tool Proxy itself.  The key is defined by the Tool Consumer and the secret by the Tool Provider.

This Registration process and credential exchange can be very fast, usually only requiring the enrolling institution to provide the provider’s public registration endpoint.  This replaces the cumbersome, out-of-band credential exchange of LTI 1.

Architected Services

LTI 2 not only defines some common services, such as Tool Settings, but also provides the architecture for bi-directional web services.  This means that new services can be defined quickly without affecting the core standard.  All that’s needed to incorporate a new service is to modify the metadata in the TC or TP and re-register.

The services that are currently defined, or are in progress, are:

• Tool Settings
  Allows a Tool Provider to store data in the Tool Consumer and associate that data with either the Tool Proxy itself, a Course, or a Link.  This has extraordinary power; for example, an adopted book can be stored with the course object in an LMS.  If that course is copied or deleted, so is the book adoption.
• Enhanced Outcomes

Allows the Tool Provider to send outcomes back to the Tool Consumer but with a) a richer palette of value types than a simple number and b) allow other learning metrics to be provided.

• Organization Hierarchy
  Allows the Tool Provider to inspect the structure of departments, courses, course sections etc.
• Roster
  Allows the Tool Provider to inspect who’s enrolled in a specific course.

Partner-Provided Services

One of the really revolutionary features of LTI 2 is that it allows custom services to be created by partners and used either between themselves, or among any distinct sub-community.  These services snap right into LTI 2.  Another benefit of partner-provided services it that it allows new services to evolve organically before being submitted for full inclusion as an architected service.

Final Thought on LTI 2

If we go back to our cannon metaphor we see a major change in this LTI level.  Now the cannonball morphs into a spacecraft.

In LTI 2 the launch is still important, just as it’s still the most critical moment in the life of a spacecraft.  But after launch the interoperability is only beginning.  Course corrections, notifications, emergency alerts, status reports are all part of the expected interaction.

An LTI 2 environment expects that learning objects are not only launched but may then have a potentially constant stream of commands, alerts, outcomes, etc.

LTI v1.2: Post-View

As mentioned above, LTI 1.2 is a hybrid of LTI 1 and LTI 2.  It’s being released simultaneous to LTI 2.  This is much like Apple’s simultaneous release of the iPhone 5c and 5s; i.e., to different functionality / price points addressed at the same time.

Here are the characteristics of LTI 1.2.

• The LTI 1.0 launch is virtually identical.  No change needs to be made to support the LTI 1.2 launch.
• It defines the ToolConsumerProfile (the TC metadata) and makes it available to the ToolProvider.
• But there’s no definition of a Tool Profile, nor creation of a Tool Proxy.
• Consequently only TC-based services (e.g., Roster and ToolSettings) are supported.
• Furthermore, it is a declarative rather than negotiated interface.  That only means that services are presented by the TC and are not modified by any Tool Provider concern.

LTI 1.2 can provide a transitional step to LTI 1 based TCs by just adding a ToolConsumerProfile with no Registration phase required.

Comparison Chart of LTI Versions