What LTI 1.3 actually fixes, and what it does not

If you have integrated an external tool into a learning platform in the last decade you have met LTI. If you did it before 2019 you met LTI 1.1, which worked by signing a form post with a shared secret — a mechanism that was already old when it shipped and had two well-known problems.

The problems 1.3 genuinely solved

Shared secrets, everywhere. In 1.1, the platform and the tool agreed a key and secret. That secret was often pasted into a course settings page by an instructor, which meant it was in a browser, in an email thread, and frequently in a departmental wiki. Rotating it meant finding every place it had been pasted.

1.3 replaces this with OAuth 2.0 and asymmetric keys. The platform publishes a JWKS endpoint; the tool validates signatures against it. Nobody types a secret into a course page, and rotation is a key change on one side.

No real user identity. 1.1 passed whatever the platform felt like passing, which in practice meant tools received an opaque ID and a display name and had to guess about everything else. 1.3 uses OpenID Connect, so identity is a signed token with defined claims, and a tool can actually distinguish a learner from an instructor without a configuration flag.

The problem it created

Deployment is now a two-sided handshake. With 1.1 an instructor could add a tool themselves in about ninety seconds. With 1.3 the platform administrator registers the tool, the tool registers the platform, keys are exchanged, and a deployment ID ties them together. This is correct, and it means the person who can add a tool is no longer the person who wants it.

For an institution running forty tools, this is a real ongoing workload — and the honest thing to say is that dynamic registration, which is supposed to fix it, is only implemented well by about half the tools we encounter.

What to check before you believe a support claim

“Supports LTI 1.3” covers an enormous range. Ask specifically:

• Deep Linking 2.0 — can an instructor pick a specific item from the tool, or only launch it at its front door?
• Assignment and Grade Services — can the tool write a score back into the gradebook, and does it write a line item or overwrite a column?
• Names and Role Provisioning — can the tool see the roster, and is that gated per-deployment?

A tool that launches but cannot return a grade has moved the marking problem, not solved it. We have seen procurement processes where this was discovered after signature.

Our position

Cairn is certified as both platform and tool, which is deliberate — it means an institution piloting Cairn can run it inside an existing Moodle or Canvas installation as a tool, for one department, without touching the registry or the central timetable. That is the least disruptive way to evaluate anything, and it is the route about half our new institutions took.