LTI 1.1 to 1.3 Secure Tool Migration
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are an LTI tool working on supporting 1.3. According to IMS global and the 1.1 -> 1.3 migration document (https://www.imsglobal.org/spec/lti/v1p3/migr#contributors) handling re-binding of 1.1 params to a 1.3 deployment is facilitated by an oauth_consumer_key_sign in the "https://purl.imsglobal.org/spec/lti/claim/lti1p1" claim. Based on our testing, canvas does not pass this information. While we do have access to the changed resource_link_id and user_id via that claim, we are missing the most important part to ensure the security of the transition. Otherwise, anyone who had access to that tool_consumer_instance_guid could claim to represent that 1.1 launch and "steal" a re-binding.
Does Instructure have any plans to support this param in the claim? Do you have any recommendations for ensuring security during a 1.1 and 1.3 launch? We notice that Karl Lloyd @karl participated in at least some way in the forming of this migration document on the IMS global site. We were hoping for some guidance here.
Thank you.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Instructure have recently added support for the oauth_consumer_key_sign claim and I would expect it to be released to beta soon. You can see the commit here: https://github.com/instructure/canvas-lms/commit/b4eafd838e7abaaf9fd128e193cb967df504b380. Looking at the tags it seems to be tagged to be released in early July so should be available for Intructure supported deployments then.