IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Abstract

The IMS Learning Tools Interoperability® (LTI®) specification allows
Learning Management Systems (LMS) or Platforms to integrate remote Tools
and content in a standard way. LTI v1.3 and the LTI Advantage set of
services builds on and improves earlier versions of LTI, incorporating
a new model for secure message and service authentication. This
Implementation Guide provides information to lead you to successful
adoption and certification of the Core LTI v1.3 spec and LTI Advantage.

1. Introduction

This guide is provided to lead you to successful implementation of the LTI v1.3 specification and the services included in LTI Advantage. More than that, this guide helps you along the way to achieving conformance certification.

If your interested in learning more about the LTI Advantage program read more here.

Various Acronyms that are referred to in this document can be found here

1.1 Message versus Service

An understanding of the difference between a message and a service within the LTI context is important.

1.4 Conformance Certification

This document is an informative resource in the Document Set of the LTI Advantage specification [LTI-13]. As such, it does not include any normative requirements. Occurrences in this document of terms such as MAY, MUST, MUST NOT, SHOULD or RECOMMENDED have no impact on the conformance critera for implementors of this specification.

IMS offers a process for testing the conformance of products using the IMS certification test suite. Certification designates passing a set of tests that verify the standard has been implemented correctly and guarantees a product’s interoperability across hundreds of other certified products. The LTI Advantage Conformance Certification Guide [LTI-CERT-13] provides details about the testing process, requirements, and how to get started.

Conformance certification is much better than claims of “compliance," since the only way IMS can guarantee interoperability is by obtaining certification for the latest version of the standard. Only products listed in the official IMS Certified Product Directory can claim conformance certification. IMS certification provides the assurance that a solution will integrate securely and seamlessly into an institution's digital learning ecosystem.

In order to become LTI certified a paid IMS membership is necessary. Here's why: while conformance certification provides a "seal" for passing prescribed tests it is much more than that. It is a commitment by a supplier to the IMS community for continuous support for achieving "plug and play" integration. Certification implies ongoing community commitment to resolve problems, revise implementations and retest as need. For that reason, only IMS Contributing Members, Affiliate Members and Learning Tools and Content Alliance members are eligible to apply for conformance certification. Details and benefits of membership are listed here: https://www.imsglobal.org/imsmembership.html.

1.5 Product Directory Listing

The IMS Certified Product Directory is the official listing of products that have passed IMS Global interoperability. Products that are listed in this directory are guaranteed to meet the IMS standards for which they have passed testing. If you experience an integration issue with a product listed here, IMS will work with the supplier to resolve the problem. If a product is NOT listed here it has either not passed IMS testing or its certification has expired.

2. LTI Advantage Use Cases

2.1 Value Statement

Institutions adopting educational technology solutions want standardized ways to enable
the seamless integration of a diverse set of educational tool providers and learning
platforms. Tool creators and platforms also want standardized approaches to facilitate
this seamless access between solutions. LTI Advantage provides a standardized approach
that allows tools and platforms to deliver to customers a robust integration with a
consistent user experience across many platforms while lowering the cost to support and
maintain these integrations.

2.2 Use Cases - Digital Publisher

2.2.1 Case: Instructor adds publisher digital resources to course

Description: An instructor has adopted a digital solution from a publisher for use
in an online and blended learning experience. The instructor would like to be able to
use different resources in different ways. Some resources are structured as a course
and the instructor would like to have the course retain its structure in the platform.
The instructor would like to use other resources as specific discrete learning objects
in a blended learning fashion.

User Experience: The instructor logs into the institution’s LMS platform that has
been configured with the publisher’s LTI tool. The instructor launches the publisher’s
tool within the platform and selects the digital product to view a list of available
resources. The instructor selects items for inclusion in the course and submits the
selection(s). The instructor has the flexibility to pick and choose which resources to
select and can easily select all or a subset of resources. This streamlines the
instructor’s flow for completing this activity and provides them complete control over
the design or the learning activity for their students. The result is that content links
are added to the LMS course.

Description: An instructor has adopted a digital solution from a publisher for use
in an online or blended learning experience. The instructor wants to ensure that grades
are always up to date, even if grading occurs outside the flow of a student launch of
a resource.

User Experience: The student logs into the institution’s LMS platform that has been
configured with the publisher’s LTI tool. The student is working on a course that consists
of learning resources from the publisher. The student completes two learning activities
during this session. One of the activities has a short five question quiz that is machine
graded. The tool automatically creates a line item for this quiz in the platform’s
gradebook and provides the platform the maximum score and the student’s result which is
immediately visible to the course instructor. The next item is a short essay that requires
manual grading in the tool. The tool also creates a line item for this activity in the
platform gradebook that shows the instructor that it is not a final grade and is pending
a manual score. When the scoring is complete in the tool, the score is sent to the
platform gradebook immediately and does not require any interaction by the student or
instructor in the LMS platform to do so.

2.2.3 Case: Instructor reviews student engagement with materials

Description: For publisher resources, the instructor may wish to see which students have
viewed or engaged with the material. For this to happen, the Tool requests the course
roster from the Platform in order to display the list of all students. The Tool then uses
its information about student access to show which have engaged with the material and
which have not.

User Experience: The instructor accesses the Tool and navigates to a place where she
can review student engagement. She is able to review summary information of the
materials or the students to determine engagement with the materials.

LTI Specifications: LTI Core, Names and Role Provisioning Services

2.3 Use Cases - Assessment Tool Providers

2.3.1 Case: Instructor creates individual assessments in course

Description: When a Tool is used for assessment, it’s common for there to be multiple
assessments that might be used in a particular course. It’s preferable that each
assessment item can be seen and managed individually within the Platform’s course outline
or learning sequence. This is preferable to an experience where all of the assessments
for a given Tool must be grouped together under a single launch, or where the instructor
has to manage custom LTI parameters to create this experience.

User Experience: The instructor starts the add content or activity workflow of the
Platform and selects the Tool. The instructor creates an assessment in the Tool. The Tool
adds the resource link for the specific assessment into the Platform’s course outline or
learning sequence. The instructor can then move that assessment around into the proper
location in the course outline or learning sequence. Other assessments created by the same
Tool can be moved independently in the outline or sequence.

LTI Specifications: LTI Core, Deep Linking

2.3.2 Case: Instructor sees student submission status

Description: For a given assessment, the instructor may wish to see which students have
submitted and which have not. For this to happen, the Tool requests the course roster from
the Platform in order to display the list of all students. The Tool then uses its
information about student submissions to show which have submitted and which have not.

User Experience: The instructor accesses an assessment created by a Tool. She is able
to see the list of students in the course and which have submitted the assignment to the
Tool and which students have not.

LTI Specifications: LTI Core, Names and Role Provisioning Services

2.3.3 Case: Instructor grades student submissions for an assessment

Description: The grading workflow for an assessment Tool is often entirely in the Tool.
However, this grade is often then used in the Platform to aggregate score information from
across Tools and solutions, apply calculations or scales, present an aggregate grade to
the student, and sometimes report to another system of record (SIS). Therefore, the Tool
must interact with the Platform gradebook in a robust, secure, and constrained way where
the Tool has full control over the records associated with the Tool but not other parts of
the Platform’s gradebook.

User Experience: The instructor manages an assessment in the Tool, configuring settings
related to the grade. These settings are passed to the Platform automatically along with
the results of any grading activity managed in the Tool. As the instructor sets and
manages assessment grades in the Tool, these appear in the Platform’s gradebook where they
can then be used in further calculations.

LTI Specifications: LTI Core, Assignment and Grade Services

2.3.4 Case: Instructor manages multiple grades for a single assessment

Description: For some assessments from Tools, multiple grades may be reported to the
Platform. For example, the student might receive one grade for their work product and
another grade for the self-reflection they authored at the time of submission.

User Experience: The instructor manages an assessment in the Tool. Within that tool,
she is able to define multiple grades for a single resource. These are managed
automatically in the Platform gradebook including any scores added or changed in the Tool.

LTI Specifications: Assignment and Grade Services

2.3.5 Case: Instructor edits an assessment due date

Description: Due dates are important for both a Platform and a Tool to have for a
given assessment--the Platform may display this on a calendar or send notification
reminders; the Tool may need to restriction submission or handle late submissions
differently. Changes to due dates need to be coordinated for greater consistency.

User Experience: The instructor edits a due date in the Platform. The next time
that resource is launched by a user, the updated due date is received by the Tool and
the due date is updated. The instructor edits a due date in the Tool. The Tool notifies
the Platform through the Assignment and Grade Services.

LTI Specifications: LTI Core, Assignment and Grade Services

2.4 Use Cases - Interactive Tool

2.4.1 Case: Instructor creates activity in a course

Description: A Tool often has definitions of a particular type of activity or a
time-bound session for a real-time activity such as a virtual classroom experience. It’s
common for there to be a number of such unique activities that might be used in a
particular course. It’s preferable that each activity item can be seen and managed
individually within the Platform’s course outline or learning sequence. This is preferable
to an experience where all of the assessments for a given Tool must be grouped together
under a single launch, or where the instructor has to manage custom LTI parameters to
create this experience.

User Experience: The instructor starts the add content or activity workflow of the
Platform and selects the Tool. The instructor creates the activity in the Tool. The
Tool adds the resource link for the specific activity into the Platform’s course
outline or learning sequence. The instructor can then move that activity item around
into the proper location in the course outline or learning sequence. Other activity
items created by the same Tool can be moved independently in the outline or sequence.

LTI Specifications: LTI Core, Deep Linking

2.4.2 Case: Instructor sees student engagement for activity

Description: For a given activity, the instructor may wish to see which students
have accessed or participated and which have not. For this to happen, the Tool requests
the course roster from the Platform in order to display the list of all students. The
Tool then uses its information about student access to show which have engaged with
the activity and which have not.

User Experience: The instructor accesses the activity created by a Tool. She is
able to see the list of students in the course and which have participated in the
activity and which students have not.

LTI Specifications: LTI Core, Names and Role Provisioning Services

2.4.3 Case: Student receives multiple grades for an interactive tool

Description: An interactive tool may have many graded activities for students who
always access through a central point.

User Experience: The student always lands in a single place in the interactive tool,
but as they complete different activities, multiple grades are returned to the platform
gradebook.

LTI Specifications: LTI Core, Assignment and Grade Services

3. Best Practices

3.1 Migration from Previous LTI Versions to LTI 1.3

The LTI Migration Guide (currently under development) provides best practice guidance on
migrating from earlier version of LTI to LTI v1.3.

3.2 Security

With LTI 1.3, the LTI specifications have been updated to adopt current practices
in securing Web Applications by embracing OAuth 2.0 and OpenId Connect. The same best
practices that apply to any Web Applications should be applied to the development of
LTI platforms and tools, and implementors should rely on those to continually ensure
that their applications remain properly secured.

This section represents some of those established best practices as well as some
practices specific to LTI:

3.2.1 Private Key Management

For the Tool as well as the Platform, the Private Key is the cornerstone of
the security contract between the 2 entities. It is of the utmost importance
that each party ensures that access to the private keys are significantly
restricted, never shared with client runtime, stored encrypted and used
with established libraries.

Platforms and Tools should establish minimum requirements when it comes
to key strength. At the time of writing this document, LTI specifications
require platforms and tools to support RSA256 signature on a minimum key size
of 2048 bits. Platforms and tools may accept other signing algorithms such as Elliptic Curve,
and/or longer key sizes.

3.2.2 Platform's JWK Set

The use of JWK Sets is required for platforms as the only supported LTI mechanism
to expose a platform's public key(s) to a tool. JWK Sets allow the platform to offer
new keys or rotate its keys without disrupting the integration with a tool.

Keys as identified per their kid are immutable, and the tool should
consider caching the key value. It must be able at anytime
to re-query the platform's jwks_uri in case a kid is not
found in the tool's client cache.

3.2.3 Tool's JWK Set

A platform may also support a tool jwks_uri during the tool registration
rather than a static exchange of either public or private key, for the same benefit
outlined above. A tool should consider exposing a jwks_uri to take
advantage of the offered flexibility if the host platform supports it.

3.2.3.1 JWK Set and issuer domain

When possible, it is recommended the jwks_uri be under the
same domain as the iss. This intrinsically ties the Public
Key Set with the domain it is asserting, providing an additional level
of trust for the tool vendor the keys in that key set are truly validating
requests coming from that issuer.

For example, for an iss https://lti13lms.com, the
following jwks_uri can be trusted from a domain owned by the
platform vendor:

The following cannot be intrinsically trusted as coming from lti13lms.com,
as it is not under the same domain as the iss. It does not
mean it is incorrect, but it must be acknowledged by the tool vendor
that the trust of this data solely relies on the trust that the information
that are being registered are indeed originating from the actual issuer.

Similarly as for the platform's key set url, it is recommended
for tools exposing a jwks_uri to have the url be under the same domain as a
tool LTI urls.

3.2.4 Limit Access to Contexts Where the Tool is Used

Figure 1Diagram illustrating how access is controlled by context.

The client grant does not inherently restrict API calls to given contexts.
For example, when a platform grants an access token scoped to access the
names and roles provisioning service, there is nothing inherently in the
token that restricts its access to a subset of contexts. Indeed the tool
may use the same token during its validity period to query the roster
of multiple courses.

Platform implementors should therefore implement logic that applies additional
restrictions, so that a tool may not access any context but only
contexts where it is actually engaged. The definition of engaged is not
specified; a rule of thumb is the instructor of the course ought to have
made a direct indication of the intent to use the tool in the course.

The following guidelines offer some options on how this may be accomplished.

3.2.4.1 Explicit Identification of Authorization Service

In this model, during the registration process, the platform should explicitly
provide the authorization service's identity, requiring the tool to use this
specific identity as the value for the aud claim in the JWT bearer token it
will use as a consumer identity assertion when requesting an access token for a
service workflow (see IMS Security Framework document section "Using JSON Web
Tokens with OAuth 2.0 Client-Credentials).

If the platform does not explicitly provide the authorization service's
identity, it should permit the tool to use the authorization service's token
request endpoint URL as the identity for the authorization service (via the
aud claim).

3.2.4.2 Explicit Tool Adoption

In this model, a tool needs to be explicitly added to a context before to
be used. There is within the platform's user interface a list of tools used in the
course the instructor may add or remove.

The platform should then check if the tool has been added to the context
before allowing the service call to complete. If the tool is not part
of the course, the platform should deny the service request with a
Forbidden 403 http error code.

3.2.4.3 Scoped URLs

In this model, the URL to access service, present in each and every
LTI launch in the service claim, contains additional data preventing
the tool to query any context by just changing some parameters.

For example, in addition to the typical data needed to fullfil the service request
(like the context id), the URL may contain the following information:

tool identifier

a signature of the (tool, contextid) i.e. for example a sha256(context_id, client_id, platform_secret)

On reception of the service call, the platform gets the tool
identifier from the access token, and validates the URL is properly
signed and meant for the tool. This means the request is the result
of an actual launch to that tool, which means the tool was indeed
used in that context, and the service request may be completed.
If not, the service call should not go through and a Forbidden 403
http error code should be returned.

3.2.4.4 Require Resource Links

In this model, the platform will require at least one resource link
to the tool to be present in the context. If there is no link to the
tool, the tool is considered not used in the context.

3.2.5 Verify the target_link_uri

The target_link_uri passed in the request to the login initiation endpoint may
be used for selecting the redirect_uri to send
the id_token to.

3.3 Identifying the Tool to Associate to an LTI Link

While a platform should usually hold an explicit relationship between an LTI resource
link and the tool deployment that was used to create it, there are cases where that
relationship needs to be determined at runtime; this is usually the case when the resource link is transferred
between platforms. For example:

during a course export/import using common cartridge

a deep linking flow return LTI links to be launched to another tool than the one
handling the deep linking request

or when importing LTI links from a Learning Object Repository using LTI Resource Search

In all those cases, when the resource link is imported on the target platform, it needs to be
associated with a local tool deployment in order to be actually launchable;

LTI specifications do not presently define a formal tool identifier that could be used to
identify the tool needed to launch the resource link. Rather,
LTI relies on DNS domain matching as a means to associate a resource link with an
actual tool deployment, where a tool is handling one or several DNS domains. This section defines this practice.

3.3.1 Tool Domain(s)

A tool supporting LTI Resource Links should be associated with at least one DNS domain. A
platform may support associating more than one domain with a given tool. A subdomain
is considered as a distinct domain. A platform may support wildcard subdomain.

3.3.2 Domain Matching

Domain matching is the logic to associate
an LTI Resource Link to an actual tool deployment by matching the Resource Link URL's
DNS Domain with the tool's associated DNS domain(s). This is used for example to match
resource links contained in a common cartridge to tool deployments.

The matching follows the same rules as used to match a DNS domain with a TLS certificate
as defined in [RFC6125] section 6.4:

DNS domains of the tool URL and the tool's associated domains must be an exact match,
using a case-insensitive ASCII comparison. For example, a resource link URL of
https://quiz.mytool.example.com/launch/e8982 would match a tool who has quiz.mytool.example.com
as associated domain, but not a tool with solely mytool.example.com domain.

International domains containing non ASCII characters need to use the ASCII-compatible
encoding before to run the comparison.

Wildcards, if supported, only apply to the left-most label. They do not replace multiple labels.
For example, a resource link URL of https://quiz.mytool.example.com/launch/e8982 would match a tool
who has .mytool.example.com as associated domain, but not a tool with .example.com domain.

The tool deployment governs the rules on how to launch the LTI Resource Link; in particular it
defines which version to use (LTI 1.1, LTI 1.3), the parameters to include on the launch, the services
to expose and the security contract.

3.3.3 Handling Multiple Matches

This specification does not specify the behavior if more that a single tool deployment may be applied
to an LTI Resource link. A platform may decide to prompt the user, or apply a proximity order;
for example, if a course deployment conflicts with an institutional deployment,
the platform may decide to favor the course deployment.

3.3.4 Handling No Match

If the platform cannot match an existing tool deployment, it should let the user decide whether
to continue to import the Resource Link (and associate it with a tool deployment later when a matching
tool is made available).

Until the platform has an associated tool deployment for a link, it shouldn't let users
use the link (but still may choose to let them be visible).

3.3.5 Resource Links Should be Restricted to Tool's Domains

If the platform allows users to create an LTI Resource Link manually, it should ensure that the
Resource Link URL's domain matches one of the domains associated with the tool deployment
that the user chooses as the owner of the manually-created link.

4. Course Copy and Resource Links

When a course is copied in the platform, the end user expects the copied course to work with
the minimum effort. This guidelines will help the tool implementer handle the copy process
in a more automatic fashion:

4.1 Do Not Use resource_link id

The https://purl.imsglobal.org/spec/lti/claim/resource_link id is a
unique identifier for that resource link across the whole platform; this means that this id will
change on copy. Early LTI flows were based on binding a resource to that platform-generated
identifier on first launch of a new resource link, de facto resetting links on copy.

It is now preferred for a link to rely on a
dedicated URL or even better, on custom parameters to identify the actual resource to launch.
Those are preserved on copy and the deep linking flow - the preferred way to add links to a course -
allow for the tool to specify either in the ltiResourceLink definition, avoiding
cumbersome manual creation of links.

If your tool does not support the deep linking flow and must still rely on the 1st launch
content binding, you may relay on the substitution parameter ResourceLink.id.history,
a comma-separated list of resource link ID values representing the ID of the link from a
previous copy of the context, the most recent copy appearing first in the list followed by any
earlier IDs in reverse chronological order.

This would be done by registering a tool-wise custom parameter of the tool's choosing, for example:

link_history=$ResourceLink.id.history

The implementer must be aware that some resource links in that chain might actually never have been
launched at all.

Support for ResourceLink.id.history is optional and the tool implementer should have
contingency plans when a given platform does not support it.

4.2 Context History

While the custom parameters (and the url) are copied from context to context, they cannot account
for any context customization. To allow the tool to copy a course customization, and in general
to be made aware a context is a copy of another context, the LTI Core specification defines the
substitution parameter Context.id.history as a comma-separated list of URL-encoded context ID
values representing previous copies of the context, the ID of most recent copy appearing first.

If a tool needs this information, it would specify at registration time a custom parameter to be passed
in each and every launch to that tool, for example:

context_history=$Context.id.history

As with the ResourceLink.id.history, the implementer must be aware that some of the contexts
in that chain might actually never have been launched at all.

Support for Context.id.history is optional and the tool implementer should have contingency plans
when a given platform does not support it.

5. Reference implementation Guide

The Reference Implementation is an IMS implementation of LTI 1.3 Advantage which contains
both a Platform and a Tool. The reference implementation is written in
Ruby-on-Rails.
We provide source code and
a hosted version of the tool. Our reference implementation
has passed Conformance Certification and is complete with 100% automated tests. Developers
can run it locally and develop against this tool as a Platform or Tool. We are working to
have this available in multiple languages and common functionality eventually available as
libraries. From LTI 1.3 on, we will be keeping this implementation up-to-date, to have all
versions supported.

Source Code is a member-only resource.

Hosted version will be available to the public, with services being a member-only resource.

5.1 Getting Started with Hosted Version of the Reference Implementation