Learning Tools Interoperability Advantage Implementation Guide 1.3 IMS Final Release

Learning Tools Interoperability Advantage Implementation Guide

IMS Final Release
Version 1.3
IMS Final Release
Date Issued:16 April 2019
Status:This document is made available for adoption by the public community at large.
This version: https://www.imsglobal.org/spec/lti/v1p3/impl/

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.

Copyright © 2019 IMS Global Learning Consortium. All Rights Reserved.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/speclicense.html.

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.

Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/ims-glc-public-forums-and-resources.

© 2019 IMS Global Learning Consortium, Inc. All Rights Reserved.

Trademark information: http://www.imsglobal.org/copyright.html

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.

LTI Advantage includes three feature-based services: Assignment and Grade Services v2.0 [LTI-AGS-20], Names and Role Provisioning Services v2.0 [LTI-NRPS-20], and Deep Linking v2.0 [LTI-DL-20] (technically implemented as a type of message).

A service is a call that occurs between a Tool and Platform when one 'pulls' data from the other (using an HTTP GET) or 'pushes' data (using HTTP PUT or POST) to the other.

A message is a request or a response between a Tool and a Platform.

  1.2 Specification Documents

The LTI Advantage specification documents are available on the IMS website:

  1.3 Where Can I Get Help?

If you have questions or need help with implementing LTI or achieving conformance certification, here are some available resources:

  • Public Forum for all members of the IMS community.
  • Affiliate Forum for Learning Tools and Content Alliance, Affiliate, and Contributing Members.
  • IMS Contributing Members have access to private github repositories and a slack channel for LTI Project Group discussions and collaborations. Contact an IMS staff member to gain access.
  • LTI Advantage FAQs If you have a question, an answer may already be waiting. If not, please contact us.

  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.

LTI Specifications: LTI Core, Deep Linking

  2.2.2 Case: Instructor adds gradable publisher digital activities to 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.

LTI Specifications: LTI Core, Deep linking, Assignment and Grade Services

  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.

See OWASP Key Management Cheat sheet for established good practices.

  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

Illustrates context workflow between platform and tool
Figure 1 Diagram 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.

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.

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.

However, the target_link_uri is not in itself signed, and the tool implementation should rely on the https://purl.imsglobal.org/spec/lti/claim/target_link_uri claim instead to make the final decision onto which resource should be displayed.

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:

  1. 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.
  2. International domains containing non ASCII characters need to use the ASCII-compatible encoding before to run the comparison.
  3. 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).

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.

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:

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

  1. Navigate to the Reference Implementation
  2. In the top menu, open Generate Keys in a new tab.
    • Keep this page open while configuring both the Tool and Platform because you will need to copy/paste both the public + private key.
    • Note: These will only show one time. If you refresh the page, it will generate a new public + private key.
  3. In your previous tab, click Manage Platforms in top menu to begin configuration of your Platform.
    • Click Add Platform.
    • Add a name for your Platform.
    • Provide a client id. Can be random, and will be used as the OAuth2 client id later.
    • Click Save, and you should see your platform in the list.
  4. Find your Platform in the list, and click View Platform.
  5. Click Platform Keys then Add Platform Key.
    • Create a name for your Platform Key (ex: Platform Key 1)
    • Set Deployment to 1 (can be anything you want, you may set up multiple later)
    • Copy / paste the public key from the tab we left open earlier where we generated the public + private key.
    • Copy / paste the private key from the same page into the Private Key field.
    • Click Save.
  6. In much the same way, add a new course, resource link and line item to your platform.
    • For course, type of context can be 'CourseOffering'.
    • For tool link url - paste in the url we copied in step 99a.
  7. Navigate and view your Platform
    • Click Resource Links
    • View your Resource Link
    • From this page you can inspect the JWT body we are about to send to the tool.
    • You can also see the encoded JWT we are about to send to the tool.
    • Click Launch at bottom of page.
    • You just performed a LTI 1.3 Advantage Resource Link launch!
  • 1.1 Full example resource link request
  • 1.3 Full example resource link request

  • Sample Comparison (Not exhaustive, review links above)

    • Authentication Data

      • 1.1

        python
          oauth_version = "1.0"
          oauth_nonce = "fc5fdc6d-5dd6-47f4-b2c9-5d1216e9b771"
          oauth_timestamp = "1510185728"
          oauth_consumer_key = "12345"
          oauth_signature_method = "HMAC-SHA1"
          oauth_callback = "about:blank"
          oauth_signature = "TPFPK4u3NwmtLt0nDMP1G1zG30U="
        
      • 1.3

        json
          {
            "iss": "https://platform.example.edu",
            "sub": "a6d5c443-1f51-4783-ba1a-7686ffe3b54a",
            "aud": ["292832126"],
            "exp": 1510185728,
            "iat": 1510185228,
            "azp": "962fa4d8-bcbf-49a0-94b2-2de05ad274af",
            "nonce": "fc5fdc6d-5dd6-47f4-b2c9-5d1216e9b771"
          }
        
    • User Id

      • 1.1

        python
          user_id = "4676-8317-719e225aacdd"
        
      • 1.3

        json
          {
            "sub": "4676-8317-719e225aacdd"
          }
        
    • Non-Claim Data

      • 1.1

        python
          lis_person_name_full = "Ms Jane Marie Doe"
          lis_person_name_given = "Jane"
          lis_person_name_family = "Doe"
          lis_person_contact_email_primary = "jane@platform.example.edu"
          user_image = "https://platform.example.edu/jane.jpg"
          launch_presentation_locale = "en-US"
        
      • 1.3

        json
          {
            "name": "Ms Jane Marie Doe",
            "given_name": "Jane",
            "family_name": "Doe",
            "middle_name": "Marie",
            "picture": "https://platform.example.edu/jane.jpg",
            "email": "jane@platform.example.edu",
            "locale": "en-US",
          }
        
    • Course

      • 1.1

        python
          context_id = "c1d887f0-a1a3-4bca-ae25-c375edcc131a"
          context_title = "CPS 435 Learning Analytics"
          context_label = "CPS 435"
          context_type = "CourseOffering"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/context": {
              "id": "c1d887f0-a1a3-4bca-ae25-c375edcc131a",
              "title":  "CPS 435 Learning Analytics",
              "label": "CPS 435",
              "type": ["http://purl.imsglobal.org/vocab/lis/v2/course#CourseOffering"]
            }
          }
        
    • Resource Link

      • 1.1

        python
          resource_link_id = "A200d101f2c14"
          resource_link_description = "Assignment to introduce who you are"
          resource_link_title = "Introduction Assignment"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/resource_link": {
              "id": "200d101f-2c14-434a-a0f3-57c2a42369fd",
              "description": "Assignment to introduce who you are",
              "title": "Introduction Assignment"
            }
          }
        
    • Platform

      • 1.1

        python
          tool_consumer_instance_guid = "cen-01/a527c23f-8684-41bb-9292-2b274c229c32"
          tool_consumer_instance_contact_email = "support@platform.example.edu"
          tool_consumer_instance_description = "The LMS of Example University"
          tool_consumer_instance_name = "The LMS of Example University"
          tool_consumer_instance_url = "https://platform.example.edu"
          tool_consumer_info_version = "1.0"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/tool_platform": {
              "guid": "cen-01/a527c23f-8684-41bb-9292-2b274c229c32",
              "contact_email": "support@platform.example.edu",
              "description": "The LMS of Example University",
              "name": "The LMS of Example University",
              "url": "https://platform.example.edu",
              "product_family_code": "ExamplePlatformVendor-Product",
              "version": "1.0"
            }
          }
        
    • Launch Presentation

      • 1.1

        python
          launch_presentation_document_target = "iframe"
          launch_presentation_width = "320"
          launch_presentation_height = "240"
          launch_presentation_return_url = "https://platform.example.edu/terms/201601/courses/7/sections/1/resources/2"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/launch_presentation": {
              "document_target": "iframe",
              "height": 320,
              "width": 240,
              "return_url": "https://platform.example.edu/terms/201601/courses/7/sections/1/resources/2"
            }
          }
        
    • LIS Information

      • 1.1

        python
          lis_person_sourcedid = "example.edu:71ee7e42-f6d2-414a-80db-b69ac2defd4"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/lis": {
              "person_sourcedid": "example.edu:71ee7e42-f6d2-414a-80db-b69ac2defd4",
              "course_offering_sourcedid": "example.edu:SI182-F16",
              "course_section_sourcedid": "example.edu:SI182-001-F16"
            }
          }
        
    • LTI Version

      • 1.1

        python
          lti_version = "LTI-1p1"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/version": "1.3.0"
          }
        
    • Roles

      • 1.1

        python
          roles = "student"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/roles": [
              "http://purl.imsglobal.org/vocab/lis/v2/institution/person#Student",
              "http://purl.imsglobal.org/vocab/lis/v2/membership#Learner",
              "http://purl.imsglobal.org/vocab/lis/v2/membership#Mentor"
            ]
          }
        
    • Message Type

      • 1.1

        python
          lti_message_type = "basic-lti-launch-request"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/message_type": "LtiResourceLinkRequest"
          }
        
    • Custom

      • 1.1

        python
          custom_xstart = "2017-04-21T01:00:00Z"
        
      • 1.3

        json
          {
            "https://purl.imsglobal.org/spec/lti/claim/custom": {
              "xstart": "2017-04-21T01:00:00Z"
            }
          }
        

          Revision History

        This section is non-normative.

          Version History

        Version No.Release DateComments
        v1.3 Final16 April 2019The first formal release of the LTI v1.3 Core specification and LTI Advantage Implementation Guide. This document is released for public adoption.

  A. References

  A.1 Normative references

[LTI-13]
IMS Global Learning Tools Interoperability® Core Specification v1.3. C. Vervoort; N. Mills. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/
[LTI-AGS-20]
IMS Global Learning Tools Interoperability® Assignment and Grade Services. C. Vervoort; E. Preston; M. McKell; J. Rissler. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti-ags/v2p0/
[LTI-CERT-13]
IMS Global Learning Tools Interoperability® Advantage Conformance Certification Guide. D. Haskins; M. McKell. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/cert/
[LTI-DL-20]
IMS Global Learning Tools Interoperability® Deep Linking 2.0. C. Vervoort; E. Preston. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti-dl/v2p0/
[LTI-NRPS-20]
IMS Global Learning Tools Interoperability® Names and Role Provisioning Services. C. Vervoort; E. Preston; J. Rissler. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti-nrps/v2p0/
[SEC-10]
IMS Global Security Framework v1.0. C. Smythe; C. Vervoort; M. McKell; N. Mills. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/security/v1p0/

  A.2 Informative references

[RFC6125]
Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). P. Saint-Andre; J. Hodges. IETF. March 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6125

  B. List of Contributors

The following individuals contributed to the development of this document:

Name Organization Role
Viktor HaagD2L
Dereck HaskinsIMS Global
Martin LenordTurnitin
Karl LloydInstructure
Mark McKellIMS GlobalEditor
Nathan MillsInstructure
Bracken MosbackerLumen Learning
Marc PhillipsInstructure
Eric PrestonBlackboard
James RisslerIMS GlobalEditor
James TseGoggle
Charles SeveranceUniversity of Michigan
Colin SmytheIMS Global
Claude VervoortCengageEditor

IMS Global Learning Consortium, Inc. ("IMS Global") is publishing the information contained in this document ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS Global makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

IMS Global would appreciate receiving your comments and suggestions.

Please contact IMS Global through our website at http://www.imsglobal.org.

Please refer to Document Name: Learning Tools Interoperability Advantage Implementation Guide 1.3

Date: 16 April 2019