Learning Tools Interoperability(LTI)<sup>®</sup> Advantage Implementation Guide 1.3 1EdTech Final Release
Version 1.3
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:
- LTI Core Specification v1.3 [LTI-13]
- LTI Advantage Specifications
- Assignment and Grade Services v2.0 [LTI-AGS-20]
- Names and Role Provisioning Services v2.0 [LTI-NRPS-20]
- Deep Linking v2.0 [LTI-DL-20]
- Conformance Certification Guide [LTI-CERT-13]
- 1EdTech Security Framework v1.0 [SEC-10]
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
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.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.
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.
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 hasquiz.mytool.example.com
as associated domain, but not a tool with solelymytool.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
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.
6. Comparing an LTI 1.1 Basic Launch and an LTI 1.3 Resource Link Message
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" } }
.
A. Revision History
This section is non-normative.
A.1 Version History
Version No. | Release Date | Comments |
---|---|---|
v1.3 Final | 16 April 2019 | The 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 |
|
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 Haag | D2L | |
Dereck Haskins | 1EdTech | |
Martin Lenord | Turnitin | |
Karl Lloyd | Instructure | |
Mark McKell | 1EdTech | Editor |
Nathan Mills | Instructure | |
Bracken Mosbacker | Lumen Learning | |
Marc Phillips | Instructure | |
Eric Preston | Blackboard | |
James Rissler | 1EdTech | Editor |
James Tse | Goggle | |
Charles Severance | University of Michigan | |
Colin Smythe | 1EdTech | |
Claude Vervoort | Cengage | Editor |