A really cool new feature of LTI Advantage is the ability to dynamically provision keys and security arrangements for LTI 1.3. It can even be used to set things up to evolve a key from LTI 1.1 to 1.3 and do all the needed mapping. With dynamic configuration you go into Tsugi - get a URL, paste it into the LMS - and Viola! all the data is swapped back and forth and things are set up with no copying and pasting of 4-5 URLs in each direction.
Dynamic Registration 1.0 Member Candidate Final -- Defines a way to automate the exchange of registration information between platforms and tools that use the OpenId Connect and oAuth 2 registration flows, allowing platform administrators to automate tool registrations and avoid tedious and possibly error prone manual configuration while remaining in control of granting or denying tools access to the platform.
I have been involved in the spec from its inception and along with Cengage - Tsugi is the test harness that most LMS’s use to test their configuration. There are currently three LMS’s and three tool publishers that support the protocol and the spec is going to be voted on and hopefully released soon.
My feeling is that this Dynamic Configuration will be picked up pretty quickly. Some LMS’s have a single security arrangement for all of their schools on all of their servers. Other LMS’s have a few security arrangements for each school and other LMS’s will have a distinct security arrangement at the level of department or even single instructor.
Tsugi’s data model where we have an issuer table and a key table works fine if there are very few issuers and a new issuer comes out once per ice age. The issuers expand slowly and many keys share one issuer. But it is highly manual and kind of un-fun process. But when Tsugi sees a new issuer for every new tenant/key, the issuer table fills up - and when you delete a key / tenant - the issuer might hang around forever.
To prepare for the expected rapid uptake of Dynamic Configuration, and deal with both the slowly expanding issuer set and rapidly expanding issuers - and to make Dynamic Configuration super smooth - I am going to make it so the lti_key table can can either refer to a global, pre-defined issuer and also optionally store a security arrangement that just applies to one key. There will be a few places where I will need to do some LEFT JOINs and COALESCE a few columns here and there - but I think in the long run it is a data model that will stand the test of time and work well regardless of how fast the number of issuers expand.
I think that when Dynamic Configuration becomes the norm, I can add a feature to Tsugi to allow instructors to request and provision LTI 1.3 keys - at this point only the Admin can make LTI 1.3 keys because issuers are shared across keys and instructors should not be able to tweak another instructor’s security arrangements. Post this model change, instructors can own/manage their LTI 1.1 and LTI 1.3 keys and admins will continue to own issuers. Letting instructors do LTI 1.3 requires both a functionality change (Dynamic Provisioning) and data model change as well so that folks can only edit data that belongs to them
Like always, I commit the data model changes and give all of our databases a chance to catch up well before I deploy any run-time changes that depend on those changes.
When the time comes to make the changes, there will not need to be any conversion for existing keys - even if those keys are created by the currant Dynamic Configuration feature in Tsugi. Once the run-time changes go in, the only thing that will change is new keys created using Dynamic Configuration.
And unless you are part of the IMS Work Group or the Sakai QA team - you probably have never run Dynamic Configuration and your lti_issuer table is very pretty.
I hope to have the run-time changes working, tested, and in the code base before the Dynamic Configuration spec is released.
csev
commented
2 years ago
A really cool new feature of LTI Advantage is the ability to dynamically provision keys and security arrangements for LTI 1.3. It can even be used to set things up to evolve a key from LTI 1.1 to 1.3 and do all the needed mapping. With dynamic configuration you go into Tsugi - get a URL, paste it into the LMS - and Viola! all the data is swapped back and forth and things are set up with no copying and pasting of 4-5 URLs in each direction.
The spec is almost ready to be released - from https://www.imsglobal.org/activity/learning-tools-interoperability
Dynamic Registration 1.0 Member Candidate Final -- Defines a way to automate the exchange of registration information between platforms and tools that use the OpenId Connect and oAuth 2 registration flows, allowing platform administrators to automate tool registrations and avoid tedious and possibly error prone manual configuration while remaining in control of granting or denying tools access to the platform.
I have been involved in the spec from its inception and along with Cengage - Tsugi is the test harness that most LMS’s use to test their configuration. There are currently three LMS’s and three tool publishers that support the protocol and the spec is going to be voted on and hopefully released soon.
My feeling is that this Dynamic Configuration will be picked up pretty quickly. Some LMS’s have a single security arrangement for all of their schools on all of their servers. Other LMS’s have a few security arrangements for each school and other LMS’s will have a distinct security arrangement at the level of department or even single instructor.
Tsugi’s data model where we have an issuer table and a key table works fine if there are very few issuers and a new issuer comes out once per ice age. The issuers expand slowly and many keys share one issuer. But it is highly manual and kind of un-fun process. But when Tsugi sees a new issuer for every new tenant/key, the issuer table fills up - and when you delete a key / tenant - the issuer might hang around forever.
To prepare for the expected rapid uptake of Dynamic Configuration, and deal with both the slowly expanding issuer set and rapidly expanding issuers - and to make Dynamic Configuration super smooth - I am going to make it so the lti_key table can can either refer to a global, pre-defined issuer and also optionally store a security arrangement that just applies to one key. There will be a few places where I will need to do some LEFT JOINs and COALESCE a few columns here and there - but I think in the long run it is a data model that will stand the test of time and work well regardless of how fast the number of issuers expand.
I think that when Dynamic Configuration becomes the norm, I can add a feature to Tsugi to allow instructors to request and provision LTI 1.3 keys - at this point only the Admin can make LTI 1.3 keys because issuers are shared across keys and instructors should not be able to tweak another instructor’s security arrangements. Post this model change, instructors can own/manage their LTI 1.1 and LTI 1.3 keys and admins will continue to own issuers. Letting instructors do LTI 1.3 requires both a functionality change (Dynamic Provisioning) and data model change as well so that folks can only edit data that belongs to them
Like always, I commit the data model changes and give all of our databases a chance to catch up well before I deploy any run-time changes that depend on those changes.
When the time comes to make the changes, there will not need to be any conversion for existing keys - even if those keys are created by the currant Dynamic Configuration feature in Tsugi. Once the run-time changes go in, the only thing that will change is new keys created using Dynamic Configuration.
And unless you are part of the IMS Work Group or the Sakai QA team - you probably have never run Dynamic Configuration and your lti_issuer table is very pretty.
I hope to have the run-time changes working, tested, and in the code base before the Dynamic Configuration spec is released.