Implement LTI 1.3 dynamic registration with the LMS.

[drgrice1]

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]

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

[Alex-Jordan]

I have put our WeBWorK test server on this branch, and I've asked our D2L staff to use their D2L test instance to try this out. I'll report again when there is anything to report.

[drgrice1]

Sounds good. Thanks for looking into testing this.

[somiaj]

I can't fully test, but this should probably get merged.

Should the FIXME be addressed now or left there for years?

[pstaabp]

Will merge and test.

[dlglin]

Putting some D2L observations here so that they're all in the same place.

• D2L doesn't send the registration_token. This is addressed in Add LTI 1.3 features. #2993.
• D2L gives you a checkbox to create a deployment when registering the tool. If you check the box then it successfully creates the deployment and the DeploymentID shows up in the generated conf file (unless there is already a deployment with that name, in which case it silently fails. This happens if you do the dynamic registration more than once).
• The new tool is disabled by default, so the LMS administrator will need to enable it.
• D2L allows you to change the name of the registration.

[Alex-Jordan]

We are trying this at PCC with a test WW server and a test D2L instance. Both are behind a firewall so I can't like you to them directly. Actually, I am using the branch from #2995. But when we use:

https://webwork-test.pcc.edu/webwork2/ltiadvantage/registration

We get:

The same thing appears for the D2L admin:

Do you have any insight what may be our problem?

[drgrice1]

To use this with D2L you will need a change that is made in #2993. Are you testing with that branch?

[Alex-Jordan]

Yes, I'm actually on #2995, which is on top of #2993.

[drgrice1]

I see. I think that is the same error @dlglin got without the change. That is why I asked.

This will need some more detailed debugging I think.

[Alex-Jordan]

Wait, has #2995 kept up with #2993? I know it started on top of #2993, but as updates to #2993 were made, are you routinely rebasing #2994 and #2995?

[Alex-Jordan]

@dlglin How did you determine that D2L doesn't send the registration token? Is there something I can do so that if my D2L admin tries again, I could see what is being sent in a log somewhere?

[dlglin]

@dlglin How did you determine that D2L doesn't send the registration token? Is there something I can do so that if my D2L admin tries again, I could see what is being sent in a log somewhere?

@drgrice1 and I were troubleshooting this in Slack. Are you able to log in to Slack and look at our exchange?

[Alex-Jordan]

OK, I'm following the Slack trail and reached the same http/https conclusion. I'll see about getting the IT staff to help with that.

[drgrice1]

Wait, has #2995 kept up with #2993? I know it started on top of #2993, but as updates to #2993 were made, are you routinely rebasing #2994 and #2995?

Yes, I rebase #2993 onto origin/WeBWorK-2.21, then rebase #2994 onto #2993, and then rebase #2995 onto #2994. So #2995 still has everything.

On the http/https issue, this is not the first place with LTI 1.3 authentication that this approach of determining the URL has been used. I am surprised that the login requests for general LTI 1.3 authentication work if the correct protocol is not being forwarded by the reverse proxy.

If you want to get onto Zoom and try to debug things, I could do that.

[Alex-Jordan]

On the http/https issue, this is not the first place with LTI 1.3 authentication that this approach of determining the URL has been used. I am surprised that the login requests for general LTI 1.3 authentication work if the correct protocol is not being forwarded by the reverse proxy.

I'm working with a test D2L server and a test WW server (different from the development one I regularly use). I haven't been on either one in at least a year. It's possible that the IT staff managing things made changes and everything else also stopped working. I just would not have noticed.

I explained what's going on to the IT staff who matter here, and I'll just wait to hear back about the https issue.

[Alex-Jordan]

The dynamic registration worked with our D2L test instance. It registered and created a deployment (because my D2L admin had that box checked).

She notes:

The only slightly unusual thing for this is that it did not deploy tool links with the dynamic registration; I'm not sure if that was intended or not though!

But nothing about this should be creating links, right? I think she is used to platforms where a user logs in globally, instead of to a specific course.

Should I expect the content selection tool to be created from this process, or is that something for the LMS admin to follow up with?

[drgrice1]

I am not sure what you mean by creating links, or the content selection tool being created.

Just to compare notes from other LMS's to get an understanding of what you might be meaning, when this is used with Canvas there are "placements" created that allow you to use content item selection. There are two of them that are specified on line 495 of lib/WeBWorK/ContentGenerator/LTIAdvantage.pm. As commented before that line, Moodle does not use those, and I don't know if D2L or Blackboard will need, or what the placements might be called if they do.

[drgrice1]

For reference, that is now line 668 in #2994.

[Alex-Jordan]

OK, the first thing is that while my D2L admin successfully completed dynamic registration, and checked that the deployment was created, I think she did not yet enable it. At least not for the D2L course that I work in. Probably I will hear back tomorrow.

In D2L, there is perhaps an extra layer. First there is registration, then there is a deployment. Once the deployment is enabled in a course, I can visit a course admin area where there is an "External Learning Tools" page. On that page, I can create an ELT by pasting in a URL to a webwork course or assignment. It will recognize the domain of the URL, and associate it with the appropriate deployment. This is the place where I could attach custom parameters, including ones where I make up the key, and the value is some piece of data that D2L can access. Now at this point, there are still no links in the course for a user to use. But I can go to content areas in the course and I can use a drop-down menu, where "External Learning Tools" is an option. I can select an ELT this way, say, one that goes to the WW course landing page or a particular assignment. And that finally creates an actual link for a student user to click on. I can reuse the same ELT in multiple places in the course (typically, the one to the WW course landing page).

A different way to do this is when I am in a content area, I can use the drop-down, External Learning Tools choice, but create a new one then and there instead of select one that was previously created. Except that you can't get custom parameters this way.

A third way is that I could be in a content area, and the same drop-down menu is where I would access "WeBWorK links" or whatever name has been given to the content selection tool. Whichever ones I select, those ELTs will be created and links using those ELTs will appear in that content area. Typically I use this in a hidden module to create ELTs for all the assignments in the course. And now that the ELTs exist, elsewhere in the course I use them without having to ever deal with URLs.

A grade column is set up for each assignment if we are in homework grade passback mode at the time I use the content item selection tool. Or one for the course, if in course grade passback mode. If I create an ELT without using the content selection tool, I'm unsure what happens with gradebook column creation.

Lastly, when the D2L course gets copied to a new term, I need to visit the ELT manager page, and edit each ELT's URL to use the new WW course's URL. Typically I am just replacing something like "202602" (spring 2026) with "202604" (fall 2026). Pasting that substitution a few dozen times. Then I visit that hidden module and actually use each link once, so that grade passback will function. I'm unsure what that part will be like with your new features.

Does this sound similar to the Canvas or Moodle experience? I have a sense that the "ELT" and link distinction in D2L is something that other LMSs don't have. I do like that layer though and how it helps manage things from term to term.

When my D2L admin wrote what she wrote, I guess I'm not 100% sure what she meant either. But I'll probably learn tomorrow. My best guess is that say you did this dynamic registration with MyOpenMath. I'm guessing that there would be an ELT to log you in to MyOpenMath, at the site level. (So, showing up in that ELT management page but not one that you could edit.) But I guess I don't really know for sure what she meant.

[drgrice1]

For all LMS's after using the dynamic registration URL, there is an activation step that must be performed. That is what the specification states.

In Moodle this is just a matter of clicking a button. Once that is done, then instructors can use content selection to create links in courses. Moodle does not allow editing of URL's in any way.

In Canvas, first a developer key is created which must be enabled, and then you have to activate a deployment app. Once that is done, then instructors can use content selection to create links, or they can manually create external tool links by entering a URL. Furthermore, URL's can be manually edited later.

So the experience in Canvas is similar to what you describe for D2L in that you can edit links from previous semesters. Although, courses are not copied in Canvas, but you can import content from a previous semester's course.

Yes, some external tool providers have site wide links that can be used. We haven't implemented something like that for webwork2, largely because of the course centric nature of webwork2.

[drgrice1]

After doing a bit of research on this, I don't think that they dynamic registration URL ever creates a site level link like your administrator is expecting (although I am not entirely certain what your administrator is expecting).