I struggled with how to title this. Originally, I thought about saying “LTI 1.3 is fundamentally broken”, but that isn’t really accurate.
I started creating LTI apps a couple of years ago. I started with LTI 1.1 because it is very simple to get an LTI 1.1 app up and running. I then started learning how to create an LTI 1.3 app using the celtic project library. I have learned quite a bit about LTI over the last couple of years, but I do need to stress that I am far from what would be considered a professional developer or an expert in LTI.
The root of the problem is how an LTI app is deployed. LTI 1.3 fully supports course-level deployments, but several app publishers (who tend to be traditional publishers) specifically design their platform to be installed at the account/root level. They argue that their app can be “hidden by default”, but this is only partially true. What they mean is that the app can be hidden by default from the course navigation menu, but it is absolutely not hidden from instructors/IDs within the course settings.
There are a couple of challenges presented by the scenario in which the app is not hidden from instructors.
First, it works against the goal of trying to keep the LMS clean and uncluttered. Instructors and IDs have to navigate an increasingly large list of nav items to find the things that they actually want in their course. It is particularly frustrating having an app listed here when it is only used in a small handful of courses (less than 10 courses out of thousands).
Second, instructors can see all of those options but likely do not know what they are. Any inquiries about these "mystery navigation items" will be directed to IDs or LMS admins who really don't want to be answering those questions.
Publishers will argue that they need the Deployment ID, per 1EdTech. However, they can capture the Deployment ID when the tool is launched, along with the Platform ID and Client ID. The latter two should be sufficient for the publisher to identify the “customer” as much as a root account Deployment ID (except for Inherited keys).
There are advantages to using course-level deployments for tool publishers as well. Each course can still be associated with a single “customer” via the Platform ID and Client ID but will now pass a unique Deployment ID to the tool. In a modified version of the Celtic Project’s Rating example, I was able to implement course-level customizations within the tool while still inheriting "customer level" settings.
Please share your thoughts. Perhaps I am misunderstanding something, but I still believe that there is a serious issue with how publishers are pressuring us into root/account-level deployments of LTI 1.3 apps.
