2.1 LTI Advantage Certified

Any Tool that completes certification for LTI v1.3 Core and either one or two services is considered LTI Advantage Certified. Note that this designation is only available for Tools. Learning Platforms MUST complete certification for LTI v1.3 Core and all services as listed below and are not eligible for LTI Advantage Certified.

2.2 LTI Advantage Complete

Any Tool that completes LTI Core and all three services is considered LTI Advantage Complete. For Learning Platforms LTI Advantage Complete this is the only certification option available.

3.1 Scope and Context

The Learning Tools Interoperability® (LTI®) Advantage set of specifications is designed to be the full implementation of LTI version 1.3 and the three core services enumerated below. These four components together constitute what is called "LTI Advantage". Certification to LTI Advantage requires implementation of:

• LTI Core Version 1.3
• Deep Linking Version 2.0
• Names and Role Provisioning Services Version 2.0
• Assignment and Grade Services Version 2.0

The purpose of this document is to provide details of the certification process for LTI Advantage and to describe the certifications necessary for each of the components. The conformance certification test components created by IMS Global are made available for:

• Learning Platforms that consume Tools that utilize Learning Tools Interoperability
• Tools that provides interoperability functions to be utilized by Learning Platforms

3.2 Status of this Document

IMS strongly encourages its members and the community to provide feedback to continue the evolution and improvement of the LTI Advantage specifications. Public contributions, comments and questions can be posted here: https://www.imsglobal.org/forums/ims-glc-public-forums-and-resources/learning-tools-interoperability-public-forum

3.3 Structure of this Document

The structure of this document is:

3.4 Nomenclature

3.5 Conformance Statements

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in [RFC2119].

An implementation of this specification that fails to implement a MUST/REQUIRED/SHALL requirement or fails to abide by a MUST NOT/SHALL NOT prohibition is considered nonconformant. SHOULD/SHOULD NOT/RECOMMENDED statements constitute a best practice. Ignoring a best practice does not violate conformance but a decision to disregard such guidance should be carefully considered. MAY/OPTIONAL statements indicate that implementers are entirely free to choose whether or not to implement the option.

4.1 Certification Testing Process

Conformance Certification is an IMS member benefit. You MUST to be a member of IMS Global as a Learning Tools/Content Alliance, Affiliate, or Contributing Member in order to test your product. Membership options and benefits are detailed here: https://www.imsglobal.org/imsmembership.html. The process for certification testing implementations of LTI Advantage includes the following:

• Go to the IMS Certification Test Suite for LTI Advantage. The link to the Certification Suite is: https://ltiadvantagevalidator.imsglobal.org/ltiadv/certification.html
• (Optional) Print the PDF of instructions for either the Tool or the Platform testing instructions
• Input the required setup parameters which include:
• Your Full Name
• Your Email Address
• Your Organization's Name
• The Product Name to be tested
• The Product Version to be tested
• The setup parameters for the testing that you plan to run
• Follow the instructions for running each test
• Once all tests have been successfully run, go to the Results page and submit test results for consideration of certification

NOTE: All tests MUST be passed for either the Platform or the Tool to be considered compliant and apply for certification. It is possible in rare circumstances that a Tool may not have the need for one of the three services that comprise LTI Advantage. The Certification Suite will provide feedback opportunities for those cases. However, in general all tests are always REQUIRED.

4.2 General Requirements for Certification Testing Setup

Nearly all communication between Learning Platforms and Tools in LTI v1.3 is done via the mechanism of the JSON Web Token or JWT (pronounced "jot"). This is a significant change from previous versions of LTI. Security of the JWT is achieved through the use of TLS-secured web channels, as well as signing of the JWT with asymmetric cryptosystems. Note that in production Learning Platforms may utilize most any asymmetric cryptography that is available for general use for the signing and verification of signatures for the JWT - provided that the Tools can work with the system used as well. However, for the purposes of commonality, a minimum set of RSA 256 will be required to be offered by all Learning Platforms (for the production of the keys) and Tools (for the utilization of the provided keys). As such, RSA 256 will be the only option provided in the Certification Suite provided by IMS Global for certification testing. Note, then, the following requirements:

• All Learning Platforms and Tools MUST provide the mechanisms (the libraries) for signing and verification of signatures for JWTs signed with RSA 256.
• The signing of a JWT with a public key SHALL NOT be legal or respected. All JWT instances to be signed MUST be signed only with the provided private key to be used for that portion of the communication.
• The use of Symmetric Cryptosystems SHALL NOT be considered legal and use of them is expressly forbidden.
• All communication endpoints MUST be secured with TLS (SSL-alone is expressly forbidden).

4.3 Bugs/Issues with the Certification Suite

If you encounter problems or bugs in the certification suite please send an email issue to [email protected]. You may alternatively log an issue directly in Github at https://github.com/IMSGlobal/certificationsuite-issues/issues

5.1 LTI Core testing

Four distinct payloads are REQUIRED to be tested in LTI Core testing:

• Full Student Payload
• Student Payload without PII
• Full Instructor Payload
• Teacher/Instructor Payload without PII

5.2 Deep Linking Message testing

Deep Linking is tested in a similar fashion to the LTI Core testing. The differences are that the Deep Linking OIDC workflow has its own set of URLs unconnected to the standard LTI Launch URLs. Additionally, the DeepLinkingRequest message type is different from the LTI Core launch. However, the principle is the same.

Submit an OIDC initialization request to the OIDC initialization endpoint https://ltiadvantagevalidator.imsglobal.org/ltiplatform/oidcinitialize.html, being sure that the target_link_uri is set to URL https://ltiadvantagevalidator.imsglobal.org/ltiplatform/deeplinklaunch.html for the Deep Linking launch. The redirect URL in the resulting OIDC return MUST be https://ltiadvantagevalidator.imsglobal.org/ltiplatform/deeplinkredirecturl.html, as that is the registered URL for Platform testing for Deep Linking launches. After reception of the OIDC return message from the Certification Suite, submit the Deep Linking Launch to the redirect URL noted above. The Deep Linking Response message MUST immediately be returned to the window or iFrame that sent the Deep Linking Request message. Once the Request has been submitted and the Response received, please press the "Continue" button to begin the testing. Run each test in the same manner as was done with the LTI 1.3 payloads.

The required tests for Deep Linking are:

5.3 Names and Role Provisioning Services Testing

The Names and Role Provisioning Services is one that is called by the Tool into the Learning Platform based on the parameters sent in the LTI Core launch. As such, the certification for this service will begin in a similar fashion to the LTI Core 1.3 testing. An LTI 1.3 Launch Payload will be sent to the Certification Suite that contains the required Names and Role claims. From that point the testing will begin.

Find the Names and Role payload submission page in the Certification Suite (it is the first page following Deep Linking testing). Submit a standard LTI 1.3 Instructor launch utilizing the exact OIDC workflow from section 3.1.4 above. Be sure to include the Names and Role claims in the message. Once the Payload has been submitted, please press the "Continue" button to begin the testing. Run each test in the same manner as was done with the LTI 1.3 Core payloads.

The required tests for the Names and Role Provisioning Services testing are:

5.4 Assignment and Grade Services Testing

The Assignment and Grade Services (AGS) is different from other testing, in that it is split into working with two separate payloads to simulate real-world usage of grade services. AGS is called by the Tool into the Learning Platform based on the parameters sent in the LTI Core launch. As such, the initialization of the payloads for this service will begin in a similar fashion to the LTI Core 1.3 testing. An LTI 1.3 Launch Payload will be sent at two different points, each payload to the Certification Suite MUST contain the required AGS claim. From that point the testing will begin for each of the payloads sent.

Find the first AGS Payload submission page in the Certification Suite (it is the first page following Names and Role testing). The Platform will be required to submit a student payload only with the OIDC workflow as a standard LTI 1.3 launch, being sure to include the AGS claim in the message. Once the Payload has been submitted, please press the "Continue" button to begin the testing. Run each test for this payload in the same manner as was done with the LTI 1.3 Core payloads.

The required tests for the first Assignment and Grade payload are:

At this point, if the previous testing has been successful, then we have used the lineitems URL in the LTI 1.3 launch to create two separate lineitem URLs for the provided lineitems URL. This means that at least two gradable (in our testing case) items will exist in the tested platform. (It is a good time to double-check that this is indeed true before continuing.) At this point the testing shifts to a second payload context - to fully test the potential of the AGS services provided by the platform.

Find the second AGS Payload submission page for in the Certification Suite (it is the next page following creation of the second Line Item in testing). The Platform will be required to submit a second student payload only with the OIDC workflow as a standard LTI 1.3 launch, being sure to include the AGS claim in the message to the new context. Again note that it is imperative that a different context be used here, as the idea is to prove that the AGS implementation can differentiate between calls to different contexts in the platform. Once the new Payload has been submitted for the new context, please press the "Continue" button to begin the testing. Run each test for this payload in the same manner as was done with the LTI 1.3 Core payloads

5.5 Submission of Completion

Please Submit your Testing Results from the Results page. The form for submission MUST be completed in full. The form contains the following inputs:

Following submission of this form you will receive an email detailing the test results that are submitted for consideration.

6.1 LTI Core testing

Tool Testing for the 1.3 Core is split into 4 separate sections.

6.2 Deep Linking Message testing

Deep Linking is tested in a similar fashion to the LTI Core testing. The exceptions are that the Deep Linking Payload is different and is sent (in some cases) to a different URL (based on Tool choices).

The following tests are done to test the Deep Linking workflow:

6.3 Names and Role Provisioning Services Testing

Names and Role Provisioning Services is tested as pure service (without any UI). The Tool is required to acquire an OAuth2 token from the IMS Global testing OAuth2 server and then do the GET to the known service instantiation URL communicated in the testing setup. Note that the first test is a launch - it is optional but can be done if there is no consequence for doing additional instructor launches.

The required tests for the Names and Role Provisioning Services testing are:

6.4 Assignment and Grade Services Testing

Assignments and Grade Services (AGS) is tested as pure service (without any UI). The Tool is required to acquire the OAuth2 tokens from the IMS Global testing OAuth2 server necessary to interact with the AGS system. Testing for AGS for the Tool is very different from all other testing in the Certification Suite.

Since it is possible to jump directly to testing for AGS, the Certification Suite provides the place to launch a standard, Learner-based LTI 1.3 launch into your Tool. However, that is the only prescribed test in the Certification Suite.

After that launch it is the responsibility of the Tool alone to work with the AGS API to create lineitems and scores in the Certification Suite. All interaction with the Gradebook simulated by the Certification Suite can be viewed on the Results page.

6.5 Submission of Completion

Please Submit your Testing Results from the Results page. The form for submission will have to be completed in full. The form contains the following inputs:

Following submission of this form you will receive an email detailing the test results that are submitted for consideration.