An App Store for Web-Based Instruction

Tue May 27 0:21:00 2014 EDT (-0400 GMT)

LTI Connections from LMS to other nodes
Do what you do best, and link to the rest. A lesson of the web learnt quickly by those who’s success depends on being creative online.

The latest released version of Sakai, version 2.9.3, improves on the existing features that allows for the connection of Sakai courses to external tools. The forthcoming version of Sakai, Sakai 10, takes this provision even further.

The biggest improvement is institutionalizing the configuration process to allow approved external tools to appear as peers to Sakai’s own tools when instructors choose what they would like to add to their course site, especially in Sakai 10.

The Sakai tool and the specification that supports the connection is the Learning Tools Interoperability (LTI) specification.

Presently, in the Brock University context, instructors need to know that the Brock University service, web-based tool or Publisher they are interested in integrating into their course: exists, supports LTI specification and that Isaak/Sakai can be connected through LTI. The instructor then must contact administrators to have the connection added to his/her course. The connection is only made once the proposed integration has met Brock University’s technical and privacy standards. This new model of pre-approved tools and their listing alongside other Sakai tools now only requires the instructors interest – prompted from any source, including students previous experience.

This ability to add tools alongside Sakai’s current listing of possible tools also provides an opportunity for university services to tightly integrate with courses in addition to making instructors aware that they exist.

The following posting discusses (in too much depth at times) the current status, the Sakai tool and LTI specification, examples of tools that could be integrated and a framework for the selection of tools to be added to this “App Store for Instructors”.

In Summary: We’d like the right kind of developers, on and off our campus, to embrace LTI and further propose an integration to our LMS. We think we have a high bar for accepting proposals, but we think the benefits are large and its the future of innovation in (or adjacent to) the institutional LMS.


As Isaak, Brock University’s Sakai-Based Learning Management System (LMS), completes its sixth year of operation at Brock University, the choice of the Sakai CLE as our LMS remains a good one. Its simplicity, robustness and the amount of control Brock University retains over the platform serves all parties well. Sakai has matured into a reliable tool for institutionally supported eLearning and its latest enhancement of external tools follows the modern web mantra: Do what you do best and link to the rest.

In the last five years other LMS offerings have innovated within the LMS more than Sakai has. This could be associated with the Sakai Foundation focusing on the new and different Sakai OAE product, which has many social features but primitive assessment tools, or it could be a cultural difference between the products with companies behind them and those without (it is no longer as simple as open and closed source companies and products). Sakai has not had recent extensive change to its inner workings or any major features added to its tools. Instead, Sakai has been a model of the IMS Global Learning Consortium’s Learning Tools Interoperability (LTI) specification described on the IMS web site.

Embracing LTI and an external tools model allows innovation and specialization to happen within the smaller scales in which they both thrive. The role of the LMS is to perform the general teaching a learning tasks it handles well, readily and reliably. The tools in the LMS need to be as good as they can be, but for all types of learning. The multi-disciplinary, multi-pedagogy imperative of one LMS for one institution creates a tension between the different uses of one common tool for all LMS sites. Adopting external tools and treating them as equal partners in the LMS begins to address this issue with little organizational cost.

The LTI specification is an open, cross-LMS specification for authenticating to a service external to the LMS. The specification allows an LMS to pass a range of information. The ranges starts with nothing more than the status of being authenticated by the LMS or much information as important details like the refering course code/name, real name and usernames, E-Mail address and additional arbitrary properties.

The LTI specification is secure (when run over SSL/HTTPS), based on a pre-shared key to verify information and LMS’ right to refer individuals to the destination service.

In practice, students and instructors are given access to tools that are more focused to specific tasks like discussion, feedback, document collaboration tools or tools unique to a subject area and publisher content which may be behind a cumbersome paywall.

Today, as implemented at Brock University, instructors must go through the Centre for Pedagogical Innovation (CPI) to add these LTI based connections to their courses. This ensures privacy and security concerns can be reviewed. This model often shifts instructors away from individually sending information to third parties and mitigates the risks associated with that practice. This model often prevents a model where a student might have to pay an ancillary registration fee.

The current use of LTI is secure and manages student information responsibly. The most significant problem today for existing external tools and potential tools is discoverability.

Today a few instructors at Brock University have been using the existing per-site LMS tool to connect to the CPI’s Wiki and Etherpad services, discussions/feedback hosted through Piazza, and McGraw-Hill resources. These uses are in a context in which the instructors had to contact the CPI to establish the connection for each course. If the uptake of these innovative tools more closely mirrored how instructors plan the rest of their teaching there is an opportunity for many innovative practices to flourish in Isaak/Sakai.

About the LTI specification


IMS developed LTI specification to allow remote tools and content to be integrated into LMSs.

LTI uses the simple and user-friendly OAuth 1.0a signing protocol developed by Flickr, Google, NetFlix, Twitter, and others[2]. Because of this adoption of OAuth, LTI requires a key and shared secret to sign messages (in practice, an E-Mail or telephone dialogue). This requires separate secure communications between the LMS administrator and the LTI destination. The authentication information is sent to the LTI destination through an HMAC-SHA1 signed dialogue. In practice, or at least in the Sakai case, unencrypted information is also passed in parallel with the signed information in potentially interceptable POST variables, necessitating the use of SSL/HTTPS. SSL/HTTPS is also a requirement because the further communications after the authentication that need to be protected.

Sakai has supported the Basic LTI (LTI 1.0) specification for a number of years. As an interesting aside of Canadian content is that Katherine Edwards, from McGill University, wrote much of the initial code as part of a 2008 Google Summer of Code project under the supervision of Dr. Charles Severance from the University of Michigan and chief Sakai-booster[3].

One can infer that Dr. Severance’s current involvement in the IMS’ work on LTI and the Sakai community lead to Basic LTI being quickly support in Sakai Foundation's two products. Further, related or not, Dr. Severance is presently also an employee of BlackBoard which has integrated Basic LTI into its LMS offerings. Also worth noting is that BlackBoard employees are also working actively on the next revision of the specification.

The first major commercial vendor to ship support for LTI in their native release was Desire2Learn in their 8.4.7 release[4]. Instructure, Inc. Canvas LMS also supports LTI.

Today, instructors cannot add the Basic LTI tool directly to Isaak/Sakai course sites because of its potential to “leak” information to an arbitrary URL and the potential for student information to be intercepted when an LTI destination is selected that is not using SSL/HTTPS. Instead, the CPI adds the tool and assists with the technical and privacy dialogue required to establish a connection.

There are a number of elements to consider when integrating third party tools:

  1. Privacy, and the seeking of the appropriate assurances needed.
  2. Security and implementation.
  3. The addition of the integration to the course site.

Sakai 2.9’s centralization of the administration of External Tools provides streamlines all of these elements while empowering instructors.

Privacy and Third Party Responsibilities

Brock University has a number of relevant policies and procedures about the handling of the type of information the LMS contains and its use by third parties:



Best Practices

These policies and procedures reflect The Freedom of Information and Protection of Privacy Act (FIPPA) which has been a part of Ontario legislation since 1988. On June 10, 2006, this act was amended to apply to the province’s universities.

It is important to note that many uses of LTI are internal to Brock University, and in this case the concerns are almost exclusively about the handling of private information, non disclosure and due care by other parties.

While the LTI tool itself is not the point of collection, it is however the point at which information previously collected is being used in a new way. This is enough to warrant a modified collection/use notice which the Sakai 2.9 External tool provides for and will be a requirement for potential external tools.

Brock University also requires that when a third party is given private information that third party is to provide assurances, and in many cases, evidence that they will protect private information, minimize its collection, limit (if not eliminate) its reuse and assume responsibility for breaches of privacy. This is typically done through a Brock University Confidentiality and Privacy Agreement or a comparable agreement proposed by the third party.

Our Plan at Brock University’s Centre for Pedagogical Innovation

We’re going to let experience grow a formal policy, but here’s our interim required information for a proposed new tool. Theoretically, anyone could propose a tool to us:

  • Proposed Tool Submission Examples
  • Title of tool
  • Who is submitting the tool
  • Their affiliation to Brock
  • How they can be contacted
  • A long and short description of the tool
  • An instructor to sponsor/vouch for the tool
  • Indicate if the tool uses LTI or a simple URL/GET pattern
  • If available , technical details to establish a sample connection

The CPI will then review the submission and follow-up to seek the remaining information, assurances and agreements about security and privacy.

We’ve implemented this submission proccess at

Cited Above

[1] Image From: (2010). IMS Global Learning Tools Interoperability Version 1.0. [online] Retrieved from: [Accessed: 28 Jan 2013].

[2] OAuth. (2013, January 23). In Wikipedia, The Free Encyclopedia. Retrieved 19:08, January 28, 2013, from

[3] (2008). Introducing Katherine Edwards – Google Summer of Code – Google Groups. [online] Retrieved from:!topic/sakai-dev/51aiqGsYwfc

[4] (2012). Dr. Chuck's Blog » Blog Archive » Connecting IMS Learning Tools Interoperability and SAML. [online] Retrieved from: [Accessed: 28 Jan 2013].

Comments are closed.