LTI 1.3 proposal and appeal to LMS vendors

LTI 1.3 proposal and appeal to LMS vendors

Hi, all!

I have a proposal for LMS vendors to consider: emulate Canvas’s LTI 1.3 implementation rather than rolling your own, unique implementation.

Economy of scale for tool providers and ensuring your LMS—and your customers ultimately—get supported. LearnZillion has run the accounting numbers on all things related to LTI based on our LTI 1.1 implementation and maintenance the past three years, its Canvas 1.3 implementation, and accounting for less coding effort for each addition LMS. Bottom line: it will cost us $35K to implement LTI 1.3 for any one LMS and $25K per LMS each year thereafter for maintenance. This sets a profit margin floor that we have to see for each LMS. LMSes other than Canvas and Schoology do not cross this floor at LearnZillion. We regularly disappoint customers who use less popular LMSes at LearnZillion. I’m guessing other K-12 tool providers are in a similar position for the same LMSes based on various conversations I've had with others.

Why Emulate Canvas?
We serve the K-12 market. The overwhelming majority of our LMS customers use Canvas, and Canvas has a complete and functioning 1.3 implementation. Schoology is second for us but has punted its start on LTI 1.3 for now due to COVID impacts to roadmap. Additionally, we’ve learned that some LMSes already emulate Canvas’s LTI 1.1 implementation to enable integration with tool providers. (It seems they were already ahead of the curve here! Well done!) We’ve chatted with two LMSes—one that already has their own 1.3 implementation—and they are open or committed to the idea of emulating Canvas’s.

Standards are helpful, but implementations are reality.

I’m not sure what the next action step is here to discuss with LMS vendors. If anyone has a suggestion for next steps, please chime in.

Tool providers, if you support this idea, please let this forum, and your LMS points-of-contact, know too.


Ian Lotinsky
CTO & Head of Platform
LearnZillion, a Weld North Education company

Re: LTI 1.3 proposal and appeal to LMS vendors

I am intrigued by your proposal. Are you able to elaborate on the differences you have found between the LTI implementations of different platforms which make it problematic for you to maintain a single code base for them all? Perhaps I am not using some of the LTI services which you are, but I have been able to write a single implementation which works with all IMS LTI 1.3 certified platforms, in spite of them all not being fully compliant with the specifications.

My main issue with the Canvas flavour of LTI is that it does not support the ability to specify custom parameters for specific resource links; I think this is a major shortcoming and I would not wish to see other platforms following suit.

re: proposal

I agree, I think there are lots of things to tighten up and improve across LTI 1.3 platform implementation that will make it easier for the whole edtech community to manage their integrations.

For example, a primary one right now is how all the platforms register new tools differently from each other, and I think the new tool registration service will make that process much better for everyone. We're still waiting for some initial implementations of that service, but I'm hoping it'll spread quickly once it's out somewhere.

As far as emulating one specific implementation, I don't think that's necessarily the best route. Each implementation has its problems, including Canvas'. LTI will never match everyone's needs completely, and its generic model won't exactly fit how each platform or tool works.

Each LMS is different, and will naturally approach some implementation details differently because of that, and that's OK. A tool should always take the context of their integration into account, including which LMS it's interacting with. That doesn't mean we can't improve things in areas, but assuming all differences can be standardized away causes different sets of problems, usually ones that cause confusion for the end users.


While I agree each LMS will

While I agree each LMS will approach some of the implementation details differently, I do think it would have been nice if IMS had required or recommended specific language to be used for the various registration URLs at least. It is very frustrating to have to customize our platform registration for each LMS to make sure the names for the URLs match what the LMS is asking for. It also would have been nice if IMS has recommended a single JSON configuration object or URL, like Canvas has the option for, to set all the registration information, and even a single JSON object or URL to put back in the tool to complete the registration.

Also, it would have been nice if ResourceLink.timeFrame.start, ResourceLink.timeFrame.end, and ResourceLink.timeFrame.due had been included in the substitution variables, but that's a different topic.

sad registration

Yeah, the registration is the roughest part and needs the most help. The dynamic registration spec makes it so that all those copy/paste or custom json generation steps go away and makes the process much more consistent and it defines specific json for all the data. The LMS' are all excited for the spec, but it seems to have been deprioritized for most groups fall plans given other priorities.

As a little background, the LTI workgroup purposely didn't address registration, and other things, in the initial release because trying to solve all the things from the beginning was one of the big downfalls of LTI 2.0. The hope is that since the registration spec was informed by all the problems you mentioned in practice that it'll be better at solving them than they were in LTI 2.0.


I agree, those substitution variables would be great to standardize.