OAuth Message Signing of the Outcomes Service when using an URL with query parameters
OAuth Message Signing of the Outcomes Service when using an URL with query parameters
Hello,
After using LTI (as a consumer) for a while now we came up with some problems with the message signing in the outcomes service. With some tool providers everything works great and some tool providers will get a 401 stating that the signatures do not match. After some investigation we pinpointed the problem. Some of the tool providers sign the message with the URL query parameters and some exclude the URL query parameters when signing the message. Even the known libraries do it differently. The LTI Test Suite at http://lti.tools/test/tp.php signs with the URL query parameters and a well known .net library https://github.com/andyfmiller/LtiLibrary deliberately signs without (explanation here https://github.com/andyfmiller/LtiLibrary/issues/14).
So the question is: Should the URL query parameters be used in the message signing when doing a post to the outcomes service?
Regards,
Martijn van den Berg
Re: OAuth Message Signing of the Outcomes Service
OAuth requires all parameters to be included when signing a message - this means both those in the POST body as well as any in the query string. I assume that none of the tool providers who are incorrectly signing the message are IMS certified, but if they are please refer them to us so that we can work with them to rectify the issue.
Note that I do not think this is inconsistent with the explanation you referenced at https://github.com/andyfmiller/LtiLibrary/issues/14. The statement there was to the effect that query parameters should not normally be included in an LTI launch URL; it was not that, if they were included, that they should not be included in the signature. The normal advice as regards query parameters is that they should not be used to make launch URLs resource specific - the LTI endpoint should be a fixed URL for all launches. Whilst using query parameters to identify resources can be made to work in LTI 1, this is not likely to work in LTI 2. The recommended practice is to use custom parameters to customize launch links.
The issue Martijn posted was
The issue Martijn posted was real and has been resolved in LtiLibrary 1.6.