Showing results for 
Search instead for 
Did you mean: 

LTI messages are not equivalent across different security models

LTI launch messages signed with OAuth 1.0A included the following custom parameters by default (i.e. without asking):

  • custom_canvas_api_domain
  • custom_canvas_course_id
  • custom_canvas_enrollment_state
  • custom_canvas_user_id
  • custom_canvas_user_login_id
  • custom_canvas_workflow_state

However, this does not appear to be the case with LTI 1.3 launch messages.  Is it intentional that LTI messages signed using different security models should not have equivalent contents?  Do custom parameter substitution variables exist for each of the above values so they could be requested manually in an LTI 1.3 message?


Tags (1)
2 Replies


I'm not using LTI 1.3 yet, so I'm getting this from the documentation and conversations held in the Community.

There was a question about the differences in the security model. I cannot find the post right now, but the gist was that Canvas has to follow the spec. They are using OAuth 2 instead of OAuth 1 now. The LTI 1.3 spec is vastly different than the LTI 1.1 spec. The IMS was offering an upgrade to LTI 1.1, but it was going to require so much work that Canvas decided not to support it.

If you look at the LTI Variable Substitution page in the API documentation, their Via JSON Configuration (LTI 1.3) shows placement of custom fields. That strongly suggests that sending custom values will continue to work.


Thanks for the reply.  Apart from the one message parameter which has been dropped by IMS in LTI 1.3, I believe all others have an equivalent claim in the JWT passed on an LTI 1.3 connection.  My question was really about why Canvas was not passing all the same parameters in the JWT as it does in the POST data of an OAuth-signed message.  It seems that any tool which was using any of this now missing data has to check for the relevant custom parameter substitution variable and include it in its configuration (which looks like it is possible for all the parameters I listed from the API page you referenced).  But I don't know whether this lack of equivalence is intentional or an oversight.