What LTI Actually Does, and Why It Matters

If you have ever added a tool to a course in Canvas, Moodle, Blackboard, or D2L and had it simply appear — no separate account, no roster to upload, students clicking through without being asked to sign up for anything — you have used LTI. If you have ever adopted a tool that made every student create an account and then spent the first week of term resetting passwords, you have used one that did not.

Learning Tools Interoperability is an open standard from 1EdTech. It is unglamorous plumbing, and it is the difference between a tool that fits into a course and a tool that sits beside it.

The problem it solves

An instructor wants to use an outside tool in a course. Without a standard, that means three separate problems.

Identity. Every student needs an account. Someone creates them, or the students create their own and half get it wrong. Either way there is a roster to maintain in two places, and it drifts the moment someone adds or drops.

Access. Students have to find the tool, which means a link somewhere and instructions nobody reads.

Grades. Whatever the students do in the tool has to reach the gradebook. In the absence of a standard, this is a CSV export and an import, done by hand, repeatedly.

LTI addresses all three. The LMS vouches for who the student is, launches the tool in place, and provides a channel for scores to come back.

What actually happens at launch

Worth understanding in outline, because it explains the privacy properties.

When a student clicks an LTI link, the LMS sends a signed message to the tool. That message says: here is a user, here is the course, here is their role, here is which resource they clicked. It is cryptographically signed, so the tool can verify it genuinely came from the LMS and was not forged.

The tool checks the signature, and the student is in. No password, no account creation — the LMS already established who they are, and the tool trusts that.

Notice what is not in the message: the student's password, and by default a good deal of personal information. The LMS decides what to share, and a well-behaved tool asks for very little. This is a genuine privacy advantage over tools that require their own accounts, and it is worth raising when someone asks whether an LTI tool is safe.

1.1 and 1.3, briefly

You will see two versions in the wild.

LTI 1.1 is the older one, based on OAuth 1.0a shared secrets. You generate a key and secret, paste them into the LMS, and it works. It is widely supported, simple to configure, and cryptographically dated.

LTI 1.3 is the current standard, built on OpenID Connect and JSON Web Tokens. Better security, a proper permissions model, and access to newer services. Setup involves exchanging keys between the LMS and the tool — more moving parts, though dynamic registration reduces it to pasting a single URL.

New tools should support 1.3. Supporting 1.1 as well is a kindness, because plenty of institutions run older LMS versions or have local policies that make 1.3 registration a longer conversation than it should be. A tool that supports both lets you start today and move up later.

Grade passback, the part that breaks

Scores returning to the gradebook is where implementations diverge in quality.

Under 1.3 the mechanism is the Assignment and Grade Services (AGS). Under 1.1 it is Basic Outcomes. Either can work well. What matters is what happens when the network hiccups at the moment a score is sent.

A naive implementation sends the score, gets an error, and moves on. The student sees a completed activity; the instructor sees an empty gradebook cell; the email arrives three weeks later during finals.

A good implementation queues scores, signs them, and retries until they land — and tells someone when they do not. When you evaluate an LTI tool, ask what happens to a grade if the LMS is briefly unreachable. The answer separates the tools that have been in production from the ones that have been demoed.

What to ask before adopting an LTI tool

A short checklist we would use:

• Which versions do you support? 1.3 at minimum; both is better.
• Do you support dynamic registration? It turns setup from a ticket into a paste.
• What personal data do you request at launch? Less is better. Ask them to name the fields.
• How does grade passback handle failure? Listen for "queued" and "retried."
• Do students ever need an account with you? The right answer is no.
• What happens to student data when we stop using the tool? Ask now, not later.
• Is there advertising? In a required course tool, this should be a firm no.

Why we care about this

We build an LTI tool ourselves, so we are not neutral. But the reason we built it that way is the reason above: the standard exists, it works, and a classroom tool that ignores it makes an instructor's first week worse for no good reason.

If you are evaluating anything that will live inside your LMS, the checklist is yours. It applies to us as much as to anyone.