Perhaps the language in the LTI 2.0 Implementation Guide is a little too emphatic, but an LTI 2.0 Tool Provider should be able to support a launch from an LTI 1.x Tool Consumer if it allows LTI-1p0 as a permitted value of the lti_version parameter and is able to manually create and pass across a key and secret for the tool consumer to use. So there are a few small additional requirements needed by a tool provider to include support for LTI 1 in addition to LTI 2.
Hello Stephen,
How should we (as a Tool Provider) treat consumer key in LTI 2.0 if consumer chooses key that we already have in our system? I would show some kind of error page telling that consumer with that key already exists but I can't do that because they send consumer key (tool proxy guid) as a last step of interaction after I register tool proxy with that consumer and it's too late to show errors.
Thanks
An excellent question! Originally the answer was that, since the consumer key is expected to be a GUID, this should never arise. However, for LTI 2.1 IMS proposes to allow a tool consumer to suggest a key to be used for the final tool proxy in the initial tool registration request message. In this way tool providers can stop processing the request before offering a tool proxy. For now, however, your main choices, as I see them, are:
- Do not update the tool proxy with the proposed key when the tool consumer accepts it and contact the customer as their launches will fail (you could return a status=failure parameter when returning the user as well as an lti_msg parameter to explain).
- Add support for duplicate keys provided their secrets are different, and use a different ID when referencing the tool proxy. Validating incoming requests would then need to check the signature with the secret from each matching record to determine which customer it was coming from. Certainly not ideal, but possible.
No, I don't expect this to happen but I'm just trying to cover all possible cases.
Thank you for your suggestions, I think I'll go with option 2 because it's automated.
But now another question comes to my mind. What will happen when Consumer registers for two different set of tools (different registration urls). We will then have different Consumer records for same Consumer. Again, this would be a problem only if we need to track Consumers and their usage of our Tools in some way.
I suppose this could be solved by including consumer authentication as part of Deployment UI after receiving tool proxy registration request. This would allow us to match consumer records.
Again, thank you Stephen for your suggestions.
Another excellent question and one which will hopefully be resolved in LTI 2.1 which will introduce the ability to re-register with a tool provider.
In the meantime, with LTI 2.0, you have little choice but have multiple registrations with the same tool consumer if they want to add other tools. You could try using the tc_profile_url or launch_presentation_return_url URLs (or at least their domains) to identify those coming from the same tool consumer. Or, as you suggest, you may have given customers some form of key which allows them to identify themselves during the registration process.
In the meantime, with LTI 2.0, you have little choice but have multiple registrations with the same tool consumer if they want to add other tools. You could try using the tc_profile_url or launch_presentation_return_url URLs (or at least their domains) to identify those coming from the same tool consumer. Or, as you suggest, you may have given customers some form of key which allows them to identify themselves during the registration process.