Learning Tools Interoperability (LTI)® Advantage Implementation Guide

학습 도구 상호운용성 확장 기능 구현 가이드

문서 식별 안내. 1ETK-LTI-IMPL-13:2025는 1EdTech Korea의 내부 관리번호이며 1EdTech Consortium이 부여한 공식 표준번호가 아니다. 기술적 해석과 적합성 판단에는 1EdTech Consortium의 영어 원문을 기준으로 한다.

요약

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 Core 표준 v1.3 [LTI-13]
• LTI Advantage Specifications
  LTI Advantage 표준
  • Assignment and Grade Services v2.0 [LTI-AGS-20]
    Assignment and Grade Services v2.0(과제 및 성적 서비스) [LTI-AGS-20]
    • OpenAPI Swagger View
      OpenAPI Swagger 보기
  • Names and Role Provisioning Services v2.0 [LTI-NRPS-20]
    Names and Role Provisioning Services v2.0(이름 및 역할 프로비저닝 서비스) [LTI-NRPS-20]
  • Deep Linking v2.0 [LTI-DL-20]
    Deep Linking v2.0(딥 링킹) [LTI-DL-20]
• Conformance Certification Guide [LTI-CERT-13]
  적합성 인증 가이드 [LTI-CERT-13]
• 1EdTech Security Framework v1.0 [SEC-10]
  1EdTech 보안 프레임워크 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.
  공개 포럼: 1EdTech 커뮤니티의 모든 구성원이 사용할 수 있는 포럼.
• Affiliate Forum for Learning Tools and Content Alliance, Affiliate, and Contributing Members.
  Affiliate 포럼: Learning Tools and Content Alliance, Affiliate 및 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.
  1EdTech Contributing Members 전용 리소스: LTI 프로젝트 그룹 논의와 협업을 위해 비공개 GitHub 저장소 및 Slack 채널에 액세스할 수 있다. 액세스 권한을 얻으려면 1EdTech 직원에게 문의해야 한다.
• LTI Advantage FAQs If you have a question, an answer may already be waiting. If not, please contact us.
  LTI Advantage FAQ: 질문이 있는 경우, 답변이 이미 준비되어 있을 수 있다. 그렇지 않다면 문의할 수 있다.

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:

https://lti13lms.com/.well-known/jwks.json

https://apps.lti13lms.com/app/38901-345890-aqd/keys

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.

https://lti13lms.appportal.com/.well-know/jwks.json

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:

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:

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

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

3.3.1 Tool Domain(s)

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

3.3.2 Domain Matching

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

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

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

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

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

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

3.3.3 Handling Multiple Matches

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

3.3.4 Handling No Match

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

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

3.3.5 Resource Links Should be Restricted to Tool's Domains

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

4. Course Copy and Resource Links

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

4.1 Do Not Use resource_link id

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

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

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

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

link_history=$ResourceLink.id.history

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

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

4.2 Context History

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

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

context_history=$Context.id.history

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

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

5. Reference Implementation

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

• 1.1 Full example resource link request
  1.1 전체 예제 리소스 링크 요청
• 1.3 Full example resource link request
  1.3 전체 예제 리소스 링크 요청
• Sample Comparison (Not exhaustive, review links above)
  샘플 비교(포괄적이지 않음, 위 링크를 검토할 것)

Authentication Data

LTI 1.1

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="

LTI 1.3

{
"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

LTI 1.1

user_id = "4676-8317-719e225aacdd"

LTI 1.3

{
"sub": "4676-8317-719e225aacdd"
}

Non-Claim Data

LTI 1.1

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"

LTI 1.3

{
"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

LTI 1.1

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

LTI 1.3

{
"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

LTI 1.1

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

LTI 1.3

{
"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

LTI 1.1

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"

LTI 1.3

{
"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

LTI 1.1

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"

LTI 1.3

{
"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

LTI 1.1

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

LTI 1.3

{
"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

LTI 1.1

lti_version = "LTI-1p1"

LTI 1.3

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

Roles

LTI 1.1

roles = "student"

LTI 1.3

{
"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

LTI 1.1

lti_message_type = "basic-lti-launch-request"

LTI 1.3

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

Custom

LTI 1.1

custom_xstart = "2017-04-21T01:00:00Z"

LTI 1.3

{
"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

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:

한국어 번역