Learning Tools Interoperability(LTI)<sup>®</sup> Advantage Implementation Guide 1.3 1EdTech Final Release

Learning Tools Interoperability (LTI)®Advantage Implementation Guide

1EdTech Final Release
Version 1.3
1EdTech 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.

1EdTech 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 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2019 1EdTech Consortium. All Rights Reserved.

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech 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 1EdTech 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 1EdTech Consortium, Inc. All Rights Reserved.

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

Abstract

The 1EdTech 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 Learning Tools Interoperability ™, 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 1EdTech 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 1EdTech community.
  • Affiliate Forum for Learning Tools and Content Alliance, Affiliate, and Contributing Members.
  • 1EdTech Contributing Members have access to private github repositories and a slack channel for LTI Project Group discussions and collaborations. Contact an 1EdTech 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

1EdTech offers a process for testing the conformance of products using the 1EdTech 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 1EdTech can guarantee interoperability is by obtaining certification for the latest version of the standard. Only products listed in the official 1EdTech Certified Product Directory can claim conformance certification. 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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.

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.

  1.5 Product Directory Listing

The 1EdTech Certified Product Directory is the official listing of products that have passed 1EdTech interoperability. Products that are listed in this directory are guaranteed to meet the 1EdTech standards for which they have passed testing. If you experience an integration issue with a product listed here, 1EdTech will work with the supplier to resolve the problem. If a product is NOT listed here it has either not passed 1EdTech 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.

When a Tool wants to use an LTI service, it must first request an access token from the Authorization Service (AS). To do so, it must assert its identity by providing the AS with a JWT as its client credentials.

Note: Section 5 in [RFC7523] the aud claim's entry calls out these values as needing out-of-band agreement amongst the involved parties.

sub

This is an identifier for the subject for which the access token is to be granted.

In the LTI case, since it is using client credentials grant, that's the LTI Tool itself, identified by its OAuth 2 Client Identifier obtained during the registration with the registrar (Platform or AS).

The AS will eventually be giving service access tokens that the subject (the tool itself) can use to make LTI service calls. It's clear from these specifications that in the LTI case, the OAuth 2 client identifier must act as the value for the sub claim.

The appropriate references for this value are:

  • [RFC7519] (section 4.1.2)
  • [RFC7523] (section 3, point 2)
  • [SEC-10] 1EdTech Security Framework (section 4.1.1)

iss

This is a unique identifier for the entity that issued the JWT.

Because this value will indicate the party issuing the Tool's JWT client assertions, it must be this entity that is associated with the keyset URL containing the keys used to sign JWTs produced by this issuer. That is, at registration, the registrar (Platform or AS) will directly associate the keyset URL with the identity of the issuer using those keys.

Because Deep Linking already asserts that the client identifier must populate the iss claim for Deep Linking Response messages, in the LTI case we must be stricter than standard OAuth and insist that the client identifier be used for both the sub claim, and this iss claim.

The Platform or AS must associate the keyset URL with the issuer, and thus it must know the identity of the issuer at registration time (when it receives the keyset URL).

The appropriate references for this value are:

  • [RFC7519] (section 4.1.1)
  • [RFC7523] (section 3, points 1, 9)
  • [SEC-10] 1EdTech Security Framework (section 4.1.1)

aud

This is a unique identifier for the authorization server. In the LTI case, this is the identity of the AS from which LTI Tools will request service access tokens.

When registering with the registrar (Platform or AS), the Tool will, as a result of successful registration, receive the identifier for the AS which must populate this claim.

The appropriate references for this value are:

  • [RFC7519] (section 4.1.3)
  • [RFC7523] (section 3, point 3)
  • [SEC-10] 1EdTech Security Framework (section 4.1.1)

The following sections represent 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 1EdTech 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.

  5. Reference Implementation

The Reference Implementation is an 1EdTech 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.

  A. Revision History

This section is non-normative.

  A.1 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.
28 May 2019
  • Adds more detail about JWTs to section .
  • Removes the Reference Implementation Guide section in favor of including directly with the Reference Implementation.

  B. References

  B.1 Normative references

[LTI-13]
1EdTech Learning Tools Interoperability (LTI)® Core Specification v1.3. C. Vervoort; N. Mills. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/
[LTI-AGS-20]
1EdTech Learning Tools Interoperability (LTI)® Assignment and Grade Services. C. Vervoort; E. Preston; M. McKell; J. Rissler. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/lti-ags/v2p0/
[LTI-CERT-13]
1EdTech Learning Tools Interoperability (LTI)® Advantage Conformance Certification Guide. D. Haskins; M. McKell. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/cert/
[LTI-DL-20]
1EdTech Learning Tools Interoperability (LTI)® Deep Linking 2.0. C. Vervoort; E. Preston. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/lti-dl/v2p0/
[LTI-NRPS-20]
1EdTech Learning Tools Interoperability (LTI)® Names and Role Provisioning Services. C. Vervoort; E. Preston; J. Rissler. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/lti-nrps/v2p0/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[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
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7519
[RFC7523]
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. M. Jones; B. Campbell; C. Mortimore. IETF. May 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7523
[SEC-10]
1EdTech Security Framework v1.0. C. Smythe; C. Vervoort; M. McKell; N. Mills. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/security/v1p0/

  C. List of Contributors

The following individuals contributed to the development of this document:

Name Organization Role
Viktor HaagD2L
Dereck Haskins1EdTech
Martin LenordTurnitin
Karl LloydInstructure
Mark McKell1EdTechEditor
Nathan MillsInstructure
Bracken MosbackerLumen Learning
Marc PhillipsInstructure
Eric PrestonBlackboard
James Rissler1EdTechEditor
James TseGoggle
Charles SeveranceUniversity of Michigan
Colin Smythe1EdTech
Claude VervoortCengageEditor

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

1EdTech 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.

1EdTech would appreciate receiving your comments and suggestions.

Please contact 1EdTech 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

Specification Images: