Basic Overview of how LTI ^® Works

Today’s education market includes a growing number of high quality web-based applications that enhance teaching and learning. These applications range from general communication tools for chat and virtual classrooms to domain-specific learning engines for particular subjects like mathematics or history.

Ideally, any Learning Management System (LMS) ought to provide access to these myriad learning applications. It ought to be possible to mix-and-match these applications within the context of any given course. To this end, some LMS vendors have developed proprietary extension frameworks that make it possible to “plug-in” external applications. Instructors and students navigate into the learning applications by traversing carefully crafted hyperlinks, and data flows between the two systems via custom communication protocols.

While these proprietary solutions often work nicely, they have a high total-cost-of-ownership because each integration represents a point solution that must be re-invented for each LMS / learning application pair.

The 1EdTech LTI standard aims to deliver a single framework for integrating any LMS product with any learning application. This document introduces the conceptual foundations and architectural principles that underlie the LTI standard.

Objectives

The objectives of the LTI standard are:

• To provide a simple mash-up style deployment model consisting of a URL, key, and secret which the LMS administrator or the course instructor can enter into the LMS.
• To define a protocol for launching an external application from an LMS in a way that supports single-sign-on and which preserves the learning context and user roles within that context.
• To make links to external applications portable by defining data elements that can be embedded in 1EdTech Common Cartridges.

Key Concepts

The basic workflow for using LTI starts when the Instructor or LMS administrator gains access to an externally-hosted learning tool. The tool's administrator provides the administrator or instructor a URL, key, and secret for the Tool.

For the Instructor use case, they generally add a LTI tool into their course structure as a resource link using the LMS control panel. The instructor enters the URL, secret, and key into as meta data for the resource link. When students select the tool, the LMS uses the URL, secret, and key information to seamlessly launch the student into the remote tool in an iframe or new browser window.

For the Administrator use case, they generally add a "virtual tool" to the LMS, entering the URL, secret and key. Once this is done, Instructors simply see the newly configured LTI tool as another tool or activity to be placed as a resource link in their course structure. The Instructors and students may not even be aware that the tool they are using is running out side of the LMS. They simply select and use the tool like any other tool that is built-into the LMS.

In both cases, the external tool receives a Launch request that includes user identity, course information, role information, and the key and signature. The launch information is sent using an HTTP form generated in the user's browser with the LTI data elements in hidden form fields and automatically submitted to the external tool using JavaScript. The data in the HTTP form is signed using the OAuth (www.oauth.net) security standard so the external tool can be assured that the launch data was not modified between time the LMS generated and signed the data and the time that the Tool received the data.

Once the launch request is received, the tool may choose to redirect the user's browser to some other URL, or it may render the requested user interface straight-away.

Terminology

While the primary use cases for the 1EdTech LTI standard are to connect tools to Learning Management Systems, we imagine that there will be many other use cases that use this specification as a simple single-sign-on (SSO) that includes role and context. SO in the specification documents we use more abstract terminology to describe an LMS, learning tool, and a course.

Tool Provider

A Tool Provider exposes interfaces to one or more tools. As illustrated in Figure 1, it is useful to think of the Tool Provider as a wrapper around a tool. In this sense, the Tool Provider represents the entire system of Tool plus its interfaces.

Tool Consumer

Instructors and students typically access Tools by activating links from within an LMS. But the LTI standard supports other scenarios, too. For example, you might want to launch a learning tool from Facebook, or your Google home page. Any system that offers access to a Tool is called a Tool Consumer.

Context

Links for Tools typically appear in the context of some course. But they may appear within other types of groups. For example, links might appear within the context of a student organization, club, study group, etc. Since Tools may be launched from many different types of contexts, the LTI Specification rarely uses the term “course” and instead uses the more general term “context.”

Resource Link

The Tool Consumer uses Resource Link entities to generate clickable links within its user interface. Each Resource Link has a title which defines the text that should appear in the clickable link plus an optional description which should appear alongside the link.

Having introduced the key concepts featured in the LTI standard, let's look at some of these ideas in more detail.

LTI Data Elements

The following is a subset of the information that the Tool Consumer (TC) sends to the Tool Provider (TP).

resource_link_id=88391-e1919-bb3456
This is an opaque unique identifier that the TC guarantees will be unique within the TC for every placement of the resource link

resource_link_title=Week One Wiki
A title for the resource. This is the clickable text that appears in the link.

user_id=0ae836b9-7fc06f-66ac545
Uniquely identifies the user. This should not contain any identifying information for the user. Best practice is that this field should be a TC-generated longterm “primary key” to the user record – not the “logical key". This parameter is recommended.

user_image=http://....
This image is suitable for use as a "profile picture" or an avatar representing the user.

roles=Instructor
This attribute is comma-separated list of one or more roles. Instructor and Learner are the most commonly used roles.

lis_person_name_given=Jane
lis_person_name_family=Public
lis_person_name_full=Jane Q. Public
lis_person_contact_email_primary=usr@schl.edu
These fields contain identifying information about the user account that is performing this launch. These parameters are recommended unless they are suppressed because of privacy settings in the TC.

context_id=82-006f-6783c545
This is an opaque identifier that uniquely identifies the context that contains the link being launched.

context_title=Design of Personal Environments
context_label=SI182
A title of the context – it should be about the length of a line. The label for the context is intended to fit in a column.

oauth_consumer_key=lmsng.school.edu
oauth_signature=Xddn2gaKxCdcc%3D
These and other OAuth fields are used to properly sign and secure the contents of the launch data. The oauth_consumer_key is the key that was originally issued by the Tool Provider and entered into the Tool Consumer by the administrator or instructor as shown in the sample launch form at the end of this document.

Tool Consumer Privacy Issues

The Tool Consumer will generally provide facilities for either the administrator or an instructor to obtain a URL, key, and secret and create resource links which can be added to course contexts.

The LTI Specification is very sensitive to the policies around releasing identifying information about users to Tool Providers. Most Tool Consumers allow the administrators, instructors, and at times even students control whether or not their personal information is shared with the Tool Provider. Different Tool Providers will be given differing levels of trust and hence more or less identifying information will be sent to the Tool Provider.

The Specification includes opaque identifiers which allow a Tool Provider to uniquely identify each of the users and their roles without having any identifying information.

Tool Provider Design Issues

While the 1EdTech Learning Tools Interoperability protocol is relatively straightforward, there are several issues that tool developers should consider when designing an application.

Multi-Tenancy

Since a tool will be used by many organizations, course, and users, it is important to keep the various instances of the tools separate. For example, the same person with the same E-Mail address may be a system administrator at one school, an instructor at a different school, and a student at a third school. Even though the individual is the same person their roles and permissions cannot flow between the different contexts. Best practice for Tool Providers is to concatenate the oauth_consumer_key and the Consumer- provided user_id together to form a composite primary for a particular user from a particular source. Similarly, the primary key for a context should be the oauth_consumer_key concatenated with the Consumer- provided context_id value.

Privacy Settings

Any fields that contain user identifiable information such as the user's name or e-mail address are optional and may or may not be included in launch data at the discretion of the administrator, instructor, or even student. Tool Providers should be prepared to handle situations where this data is not provided. In particular, the user's E-Mail address is considered optional and should not be used as a primary key for a user record in the Tool Provider.

In addition, the privacy settings for a resource link can be changed from launch to launch if an administrator, instructor or student changes their privacy settings in between launches. The tool should consider the lack of identifying information in a launch as an indication that the information is to be considered private even if it were provided for a particular user in an earlier launch.