LTI 1.1 to 1.3 Secure Tool Migration

Jump to solution
erikgoreact
Community Member

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.

Labels (3)
0 Likes
1 Solution
matthew_buckett
Community Contributor

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/b4eafd838e7abaaf9fd128e193cb967df504b380Looking at the tags it seems to be tagged to be released in early July so should be available for Intructure supported deployments then.

View solution in original post

0 Likes