LtiLibrary 1.4.2 is now available on NuGet and there is a sample to go with it. The big changes from version 1.3.3 are support for LTI 1.2 Public Draft and LTI Content-Item Message 1.0 Public Draft. You can get both draft specifications from IMS. LtiLibrary release notes are on CodePlex along with all the source code.

The Consumer and Provider websites have been updated to use LtiLibrary 1.4 (and to use the new Microsoft Identity framework so your old username is probably gone). To play around with the Content-Item Message, try this:

1. Login to Consumer. Make sure you are a teacher.
2. Create a Course.
3. In the Course Details view, open the Assignments section and click on Sample Provider Library to launch a content selector running on Provider.
4. Decide which tool you want to insert into your course, and click on Assign. This will insert the tool into your course.

You may notice that Content-Item Message 1.0 is designed as a browser-to-browser message. When the Content-Item Message handler sends the selection back to the Tool Consumer, the browser is redirected to the Tool Consumer and the Content-Item Message handler state is lost. This makes it different than the server-to-server messaging of LTI Outcomes and Tool Consumer Profile and I’m not sure how I feel about that.

The use cases imagine involve selecting multiple things and sending them back to the Tool Consumer. The process of selecting multiple things might take several complicated steps (such as a search with several filters applied). But as soon as the Content-Item Message handler sends the first selection back to the Tool Consumer, the search results would be lost. This can be overcome by making the Content-Item Message handler capable of assembling several items before sending them back to the Tool Consumer, but it seems like it would be easier to let the Content-Item Message handler send intermediate results back to the Tool Consumer via server-to-server messages with the final “I’m Done” message browser-to-browser.

What do you think?

Provider is also using the new MVC template based on Bootstrap. Consumer is still using the old template based on jQuery UI. After going through the conversion, I found it takes about the same amount of effort to create new views on either. But I suspect Provider will run on mobile devices with less fiddling.

As I mentioned above, both Provider and Consumer are using the new Microsoft Identify framework. Converting from Simple Membership to Identity was pretty straightforward, though tedious. I was surprised how often I was using identity features that are no longer supported or supported in a different way. The only significant change was in the LtiAuthorizeAttribute.OnAuthorization override which no longer adds the signed in user to the authorization cookie. Instead I simply redirect to the destination page and let the Identify framework do the dirty work. This results in one more browser request, but otherwise is quite transparent. [This is also why the browser back button will generate a “you’ve already used that Nonce” message after an LTI launch. I’ll work on that later.]