LTI 1.3 Advantage vs LTI 1.1 Migration Path for EdTech Developers

LTI exists so a school's LMS can hand a student off to an outside tool (a publisher's quiz app, a video platform, a lab simulator) without requiring that student to log in twice. Click a link in Canvas, land inside the tool, already signed in.

LTI 1.1 is the version that made this idea universal. Most LTI integrations running in production today, across most LMS platforms, still speak 1.1. It got the job done for a long stretch of years, which counts as a long life for anything built on that era's security assumptions.

LTI 1.1 runs on OAuth 1.0a with HMAC-SHA1 signatures, a shared-secret scheme that already looked dated when 1.1 launched. Two systems agree on a secret string, sign requests with it, and trust the signature. A signed request, once captured, can be replayed. Nothing in the token proves the person showing up at launch is the person who started the session, and there is no built-in defense against forged requests. A shared secret was never designed to prevent that class of attack, and institutions that treat it as sufficient eventually have to explain a breach to a school board.

None of this made LTI 1.1 unsafe in some dramatic way. It aged as any password-based system ages once the rest of the web moves on to stronger alternatives.

What LTI 1.1 Deprecation Actually Means

Deprecated does not mean dead. Links built on LTI 1.1 keep firing, students keep launching tools, and grades keep passing back and forth without complaint. What deprecation closes off is the future: new certifications stop, and on a growing number of platforms, so does the ability to create new courses on a 1.1-only connection.

CompTIA's CertMaster rollout is a clear, dated example. As of July 1, 2024, LTI 1.1 was blocked from new course creation on Canvas, Moodle, Blackboard, and D2L Brightspace. A developer trying to build a new class on a 1.1 link after that date gets an error. On July 1, 2025, the same restriction extended to Canvas TestOut EduApp and Brightspace Plugin integrations. Classes already running before those cutoffs were grandfathered in and allowed to finish. No new starts, though.

Mixing 1.1 and 1.3 links inside the same LMS course creates problems with progress tracking, grade syncing, and matching users to the right section. One course should use one protocol version consistently.

There is a procurement angle as well. Institutional RFPs regularly require certification to 1EdTech standards, and a tool stuck on LTI 1.1 cannot get that certification verified by a third party. That is a deal lost before the demo starts.

Institutions running current LMS versions will eventually be unable to create new courses with a 1.1-only tool, and there is no negotiating around that timeline.

The Core Architecture Break in LTI 1.3

Every prior version bump in LTI's history added capability without breaking what came before. LTI 1.3 makes a non-additive, breaking change to both the message format and the security model, because it rebuilds the foundation rather than extending it. Anyone planning a migration should treat this as the central fact: this is not an incremental update.

The old stack (OAuth 1.0a, HMAC-SHA1, shared secrets) is gone. In its place: OpenID Connect (OIDC) for identity, RS256-signed JSON Web Tokens, and OAuth 2.0 access tokens for the API calls that follow. Shared secrets are replaced by public and private key pairs, managed per platform registration. The platform sends the tool an OpenID token, and the tool sends the platform JWTs back. Both flows require correct implementation, and neither tolerates sloppy validation.

The launch itself turns into a multi-step handshake instead of one signed request. The platform sends a login hint. The tool redirects back to the platform's OIDC endpoint. The platform issues an id_token. The tool validates it and completes the launch. Every redirect serves one purpose: binding the launch to the actual session that started it, so a captured token cannot be replayed by a different party. That is the CSRF protection LTI 1.1 never had.

A cookie sits in the middle of this handshake. A state and nonce value gets set during OIDC initiation, and it must still be present when the token comes back for validation. That dependency matters significantly more in 2026 than it did when the spec was written, for reasons covered later in this post.

The architectural benefit of this rework is that security and message structure are no longer coupled. LTI 1.3 can adopt a new key algorithm without touching how launch messages are shaped, and the message format can evolve without forcing a new security overhaul.

Three Advantage Services and Their Old Names

LTI Advantage is three services built on top of the 1.3 security model. None of them run on the old OAuth 1.0a foundation, and none of them can be added on top of 1.1. No 1.3, no Advantage.

Each service also picked up a new name, which causes confusion for developers who learned the old terminology first. Membership Service became Names and Role Provisioning Services (NRPS). Content Item Message became Deep Linking. Basic Outcomes Service became Assignment and Grade Services (AGS).

AGS handles the most significant functionality. It creates a gradebook column inside the LMS automatically, then pushes scores, progress data, and comments back on its own, without any manual step required. CompTIA's rollout demonstrates this concretely: a student clicks one initial link, works through several assignments, and every score syncs back to the gradebook without instructor intervention. Before AGS, that workflow required manual exports or proprietary grade-passback workarounds. AGS handles both plain percentage scores and full rubric data.

Deep Linking addresses a different limitation. Under LTI 1.1, there was no standard way for a teacher to point students directly at one specific quiz or one chapter inside a tool. Deep Linking lets an instructor select a specific piece of content inside the tool and embed a direct link to it in the course, so students land exactly where intended rather than on a generic homepage.

Deep Linking's content selection menu operates within the browser context of the LMS page. That technical detail becomes a significant issue in the section on 2026 problems below.

What Content Survives the Migration Intact

The LTI 1.3 migration spec was designed to prevent anyone from having to rebuild courses from scratch. Existing links, course structures, and gradebook columns were meant to survive the transition even with the entire security layer replaced underneath them.

The mechanism is straightforward. Every LTI 1.1 parameter has a matching claim inside the LTI 1.3 id_token, so a tool can switch from 1.1 to 1.3 without requiring courses to be rebuilt or links to be migrated separately.

In practice, the transition is not entirely frictionless. Some IDs shift during the transition, and the user ID in particular can come out as a new value once 1.3 is live. That has real consequences for grade matching and roster reconciliation. The migration reduces work, it does not eliminate it, and that distinction matters the first time a roster does not reconcile correctly.

The scale evidence backs this up. Minnesota State migrated its most-used LTI integrations, including 1.6 million Kaltura LTI links, in August 2023, without breaking them. More than 90% of all new LTI link creation there now happens on 1.3. Purdue moved 1.5 million links tied to its Kaltura integration using D2L's migration API. Gwinnett County Public Schools migrated 1.8 million links and cleared out a million obsolete 1.1 links in a matter of days using D2L's migration tooling.

Platform Migration Patterns Developers Must Plan For

The LTI 1.3 version of a tool needs to live at the same fully qualified domain name (FQDN) as the old 1.1 tool, or existing links break. This is a deployment decision that must be made before migration starts.

Blackboard Learn handles this with something close to a one-click switch. When an administrator deploys the 1.3 version of a tool and Learn detects a 1.1 version already sitting at that same domain, it prompts the admin to migrate. Accepting that prompt moves every LTI 1.1 link on that domain to the new 1.3 application at once. Because this is all-or-nothing, the developer's real job is ensuring the 1.3 endpoint is fully validated before an administrator reaches that prompt.

D2L Brightspace offers several paths depending on scale. Course import and course copy handle migration automatically at the course-offering level. For bulk moves, there is a migration API, the same mechanism behind the Minnesota State, Purdue, and Gwinnett County results above. D2L's migration service also allows moving 1.1 links to a different 1.3 domain, which removes a major blocker for tool providers who changed domains during their own upgrade.

Dynamic Registration, defined under RFC 7591, lets a tool register itself with a platform through a URL, removing the manual credential exchange. Canvas and D2L's implementations work well. Moodle supports it starting at version 4.3, but only as a consumer. Its behavior when acting as a platform has known interoperability issues on record, tracked under MDL-81409. Dynamic Registration is worth building for on new deployments, but developers should not assume consistent behavior across every platform a tool might target.

Two Technical Problems Every 2026 Migration Must Solve

Third-party cookie blocking is the more significant of the two active problems, and it traces directly back to the OIDC handshake described earlier. The state cookie set during launch initiation must still be present when the id_token comes back for validation. Inside an iframe, from the browser's point of view, that cookie is classified as third-party, and a substantial portion of the browser market blocks third-party cookies by default.

Google reversed course on deprecating third-party cookies in Chrome, and its Privacy Sandbox initiative shut down entirely in October 2025. Chrome is not the primary concern. Safari, Firefox, and Brave all block third-party cookies by default, and together they represent a meaningful share of the browser market. Deep Linking is particularly exposed because its content selection flow depends on the browser context in which it runs.

1EdTech has documented this problem. A cookieless flow is on its active standards roadmap, and the public spec resources already document a postMessage-based alternative known as LTI Client Side postMessages or LTI postMessage Storage. Any migration plan built in 2026 needs to treat the postMessage storage fallback, or a tested new-tab launch path, as a real code path that receives QA coverage before launch.

Key management overhead is the second operational concern. Where OAuth 1.0a relied on shared secrets, LTI 1.3 requires public and private key pairs managed per platform registration, with rotation and validation logic that must keep working indefinitely. It is straightforward to set up correctly at launch and equally easy to neglect two years later when no one is watching certificate expiration dates.