Skip to content

Conversation

drgrice1
Copy link
Member

@drgrice1 drgrice1 commented Sep 1, 2025

This implements the specification detailed at https://www.imsglobal.org/spec/lti-dr/v1p0.

To use this the LMS administrator enters the URL https://your.webwork2.server.edu/webwork2/ltiadvantage/registration. That automatically adds the LTI 1.3 configuration for the webwork2 server to the LMS. Then the LMS administrator just needs to activate the tool.

On the webwork2 side of things the LTI 1.3 configuration for the LMS will be saved into a file in the directory webwork/DATA/LTIRegistrationRequests. The file will be named $lmsName-XXXX.conf where $lmsName is whatever the tool reported in the product_family_code subkey of the https://purl.imsglobal.org/spec/lti-platform-configuration key in the configuration webwork2 obtains from the LMS and XXXX is whatever tempfile fills in to ensure the file is unique. Note that the product_family_code is "moodle", "canvas", etc. Unfortunately, there isn't really a unique identifier that can be used here in the information sent from the LMS, so not much better can be done for the file name.

The webwork2 system administrator then needs to copy and paste the contents of that file into either the conf/authen_LTI_1_3.conf file for site wide setup, or into all of the appropriate course.conf files for course specific setup. Note that depending on the LMS the data in the file may not be complete. The specification essentially states that it is optional for the LMS to sent this value. Moodle sends the deployment_id in the returned configuration, but Canvas does not. Of course I don't know what D2L or Blackboard will do. In this case the generated will contain 'obtain from LMS administrator' for the $LTI{v1p3}{DeploymentID}. So for Canvas, at least, the webwork2 administrator will still need to communicate with the LMS administrator to obtain the deployment_id. Eventually, a user interface in the admin course could perhaps be implemented for dealing with these configurations in a nicer way than cutting a pasting from this file that is created. However, that most likely will require a change in how the LTI configurations are saved. The config file approach is a limiting factor in this.

Also, there may be additional configuration that the LMS administrator needs (or may want) to do, and how the tool is presented in the LMS when editing it may be different than how it was previously with the manual configuration approach.

For Moodle the tool that is automatically created needs to be activated (a click of a button does this), but furthermore, the administrator will probably want to edit the configuration and set the "Tool configuration usage" to "Show in activity chooser and as preconfigured tool" (it is set to "Show as preconfigured tool when adding an external tool" by default), and set "Default launch container" to "New Window" (it is set to "Embed, without blocks" by default). Also, the way the tool is presented when editing it is indistinguishable from a tool created using the manual configuration approach. This means that all aspects of the tool can be edited as before.

For Canvas even before the tool is created in the LMS there are some options that can be configured although usually they should be left with the defaults. The only things that can be changed are if certain things in the configuration from webwork2 are enabled or not. For example, placements in the configuration from webwork2 can not be added, but can only be disabled. Also, the way the tool is presented when editing it is quite different from a manually configured tool. None of the URLs can be edited, and the things that were in the configuration from webwork can only be disabled again.

Of course, it remains to be seen what D2L or Blackboard do with this.

Note that there is a little more that can be added to this. Before the tool is added to the LMS, webwork2 could present a page that allows the LMS administrator to select options for the tool. For example, the current tool name will be "WeBWorK at your.webwork2.server.edu", but that could be allowed to be changed by the LMS administrator. Note that for Moodle that can be changed later anyway, but Canvas does not provide a way to change the tool name. Also, it may be desirable to allow the administrator to determine if grade passback is allowed or not. Although, for both Moodle and Canvas this can still be done in any case.

Note that LTI 1.1 does support something like this, but I haven't found any documentation on it (although I haven't looked to hard).

@drgrice1
Copy link
Member Author

drgrice1 commented Sep 1, 2025

@dlglin: Could you help me with testing this for D2L and seeing if it needs any adjustment to support that platform?

@drgrice1 drgrice1 changed the title Implement LTI 1.3 dynamaic registration with the LMS. Implement LTI 1.3 dynamic registration with the LMS. Sep 1, 2025
@drgrice1 drgrice1 force-pushed the lti-dynamic-registration branch from ddb0074 to 5112f1e Compare September 1, 2025 14:37
@drgrice1 drgrice1 force-pushed the lti-dynamic-registration branch 2 times, most recently from d0b226b to 49670a6 Compare September 9, 2025 18:19
This implements the specification detailed at
https://www.imsglobal.org/spec/lti-dr/v1p0.

To use this the LMS administrator enters the URL
`https://your.webwork2.server.edu/webwork2/ltiadvantage/registration`.
That automatically adds the LTI 1.3 configuration for the webwork2
server to the LMS.  Then the LMS administrator just needs to activate
the tool.

On the webwork2 side of things the LTI 1.3 configuration for the LMS
will be saved into a file in the directory `webwork/DATA/LTIRegistrationRequests`.
The file will be named `$lmsName-XXXX.conf` where `$lmsName` is whatever
the tool reported in the `product_family_code` subkey of the
`https://purl.imsglobal.org/spec/lti-platform-configuration` key in the
configuration webwork2 obtains from the LMS and `XXXX` is whatever
`tempfile` fills in to ensure the file is unique.  Note that the
`product_family_code` is "moodle", "canvas", etc. Unfortunately, there
isn't really a unique identifier that can be used here in the
information sent from the LMS, so not much better can be done for the
file name.

The webwork2 system administrator then needs to copy and paste the
contents of that file into either the `conf/authen_LTI_1_3.conf` file
for site wide setup, or into all of the appropriate `course.conf` files
for course specific setup. Note that depending on the LMS the data in
the file may not be complete. The specification essentially states that
it is optional for the LMS to sent this value.  Moodle sends the
`deployment_id` in the returned configuration, but Canvas does not.  Of
course I don't know what D2L or Blackboard will do.  In this case the
generated will contain `'obtain from LMS administrator`' for the
`$LTI{v1p3}{DeploymentID}`.  So for Canvas, at least, the webwork2
administrator will still need to communicate with the LMS administrator
to obtain the `deployment_id`.  Eventually, a user interface in the
admin course could perhaps be implemented for dealing with these
configurations in a nicer way than cutting a pasting from this file that
is created.  However, that most likely will require a change in how the
LTI configurations are saved. The config file approach is a limiting
factor in this.

Also, there may be additional configuration that the LMS administrator
needs (or may want) to do, and how the tool is presented in the LMS when
editing it may be different than how it was previously with the manual
configuration approach.

For Moodle the tool that is automatically created needs to be activated
(a click of a button does this), but furthermore, the administrator will
probably want to edit the configuration and set the "Tool configuration
usage" to "Show in activity chooser and as preconfigured tool" (it is
set to "Show as preconfigured tool when adding an external tool" by
default), and set "Default launch container" to "New Window" (it is set
to "Embed, without blocks" by default). Also, the way the tool is
presented when editing it is indistinguishable from a tool created using
the manual configuration approach.  This means that all aspects of the
tool can be edited as before.

For Canvas even before the tool is created in the LMS there are some
options that can be configured although usually they should be left with
the defaults.  The only things that can be changed are if certain things
in the configuration from webwork2 are enabled or not.  For example,
placements in the configuration from webwork2 can not be added, but can
only be disabled.  Also, the way the tool is presented when editing it
is quite different from a manually configured tool. None of the URLs can
be edited, and the things that were in the configuration from webwork
can only be disabled again.

Of course, it remains to be seen what D2L or Blackboard do with this.

Note that there is a little more that can be added to this.  Before the
tool is added to the LMS, webwork2 could present a page that allows the
LMS administrator to select options for the tool.  For example, the
current tool name will be "WeBWorK at your.webwork2.server.edu", but
that could be allowed to be changed by the LMS administrator.  Note that
for Moodle that can be changed later anyway, but Canvas does not provide
a way to change the tool name.  Also, it may be desirable to allow the
administrator to determine if grade passback is allowed or not.
Although, for both Moodle and Canvas this can still be done in any case.

Note that LTI 1.1 does support something like this, but I haven't found
any documentation on it (although I haven't looked to hard).
@drgrice1 drgrice1 force-pushed the lti-dynamic-registration branch from 49670a6 to 15fe7ad Compare September 9, 2025 20:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant