LTI® 1.3 vs LTI® 1.1
1EdTech Consortium, Inc. publishes both: LTI® 1.3 is current, and 1.1 is covered by the security deprecation schedule.
LTI® 1.1 and LTI® 1.3 both launch a user from a learning management system into an external tool, and from the outside they look the same. Underneath they share almost nothing: the authentication model, the payload format, the service APIs and the registration process were all replaced.
1EdTech deprecated 1.1 in 2022. This page covers what changed, so that documentation written for either version can be recognised for what it is.
Side by side
| LTI® 1.1 | LTI® 1.3 | |
|---|---|---|
| Trust model | Shared secret, held by both sides | Public key cryptography, no shared secret |
| Request signing | OAuth 1.0a HMAC-SHA1 over the form body | JWT signed RS256 |
| Key exchange | Secret copied between consoles by hand | Each side publishes a JWKS at a URL |
| Key rotation | Coordinated manual change on both sides | Publish a new key; the other side picks it up |
| Launch flow | One signed form post | OIDC login initiation, auth request, then the token |
| Payload | Form fields (lis_person_name_full, …) | ID Token with namespaced claims |
| Replay protection | OAuth nonce and timestamp | nonce plus state, both checked by the tool |
| Reading the roster | No standard way | Names and Role Provisioning |
| Writing grades | Basic Outcomes: one score, XML over POST | Assignment and Grade Services: multiple columns, JSON |
| Content selection | Content-Item Message (an extension) | Deep Linking, part of the standard |
| Roles | Short strings (Instructor) | Namespaced URIs, with system, institution and context scopes |
| Registration | Manual entry both sides | Manual, or Dynamic Registration |
| Role names | Tool Provider / Tool Consumer | Tool / Platform |
| Status | Deprecated 2022 | Current |
Why the trust model changed
This is the change everything else follows from.
In 1.1, a platform and a tool shared a secret. The platform signed each launch with it using OAuth 1.0a, and the tool recomputed the signature to verify. Symmetric, and workable, with three problems.
The secret had to be transported. Someone copied it from one admin console into another, often by email. It could not be rotated without both sides making a coordinated change, so in practice it never was. And because verification meant holding the secret, anyone who obtained it could mint launches as that platform — against every tool it was shared with.
In 1.3 the platform signs the ID Token with a private key it never discloses, and the tool verifies with the matching public key fetched from a published key set. Nothing secret crosses between the two systems, either side can rotate keys unilaterally, and a stolen public key is worth nothing.
The cost is that a 1.3 implementation has more moving parts: an OIDC endpoint, a JWKS fetcher with caching, JWT verification, nonce storage. That work is the argument for not implementing it yourself.
Why grades changed
LTI® 1.1's Basic Outcomes could return one decimal between 0 and 1, for the resource link the launch came from, as XML wrapped in a POST. There was no way to create a second gradebook column, no way to send a comment, and no way to say "submitted, not yet marked".
Assignment and Grade Services is a JSON API. A tool can create as many line items as it needs, post a score with both an activity progress and a grading progress, attach a comment, and read back what the gradebook holds.
The practical consequence: an activity that produces several marks needed one resource link per mark under 1.1. Under 1.3 it is one link and several line items.
Why roles changed
1.1 sent roles as short strings such as Instructor or Learner, with no
namespace and no way to distinguish a course-level role from an
institution-level one.
1.3 sends namespaced URIs and separates the scopes:
http://purl.imsglobal.org/vocab/lis/v2/membership#Instructor
http://purl.imsglobal.org/vocab/lis/v2/institution/person#Faculty
http://purl.imsglobal.org/vocab/lis/v2/system/person#Administrator
The distinction matters. Somebody can be an institutional administrator and a learner in the course they are currently launching, and 1.1 could not express that difference.
What this means for older documentation
A page describing any of the following was written for 1.1, whatever its publication date says:
oauth_consumer_key,oauth_signature, or OAuth 1.0a signing- an XML configuration containing
blti:launch_url - Basic Outcomes,
replaceResultRequest, orlis_result_sourcedid - Tool Provider and Tool Consumer as the role names
- a shared secret entered on both sides
This matters because several of the highest-ranking tutorials for adding LTI® to an application are exactly this, still online and unmarked. Following one produces an integration against a specification deprecated four years ago.
If you are on 1.1 today
An existing 1.1 integration keeps working for as long as the platforms you support keep accepting it, which several still do. It is not an emergency, but it is a shrinking position: it is no longer certified, it gains no new services, and each platform decides on its own timetable when to stop.
See migrating from LTI® 1.1 to LTI® 1.3 for how to move without breaking the integration you already have.
LTIAAS supports LTI® 1.1 as well as 1.3. It is off by default, since a new integration should be built on 1.3, but it can be enabled on your account for the cases where it is genuinely needed — usually an institution whose platform cannot do 1.3 yet. Ask us if that is your situation.
Common questions
Is LTI® 1.1 still supported?
1EdTech deprecated it in 2022 and no longer certifies it, and new work should target 1.3. Many platforms still accept 1.1 launches for existing integrations, and LTIAAS can enable 1.1 on an account where an institution genuinely still needs it.
What is the biggest difference between LTI® 1.1 and 1.3?
Authentication. LTI® 1.1 signed a form post with OAuth 1.0a using a secret shared between the two systems. LTI® 1.3 uses signed JWTs verified against published public keys, so no shared secret exists to leak.
Is LTI® 1.2 a thing?
There was an LTI® 2.0 that saw very little adoption, and no widely used 1.2. In practice the versions you will meet are 1.1 and 1.3.
Can a tool support both versions at once?
Yes, and many do during a transition. Implemented directly they are separate code paths with separate registrations, so supporting both means maintaining both. On LTIAAS the two can run side by side without a second implementation.
Next
- What is LTI® 1.3? — the current launch, step by step
- Migrating from LTI® 1.1 to LTI® 1.3
- Tool, platform, provider, consumer
