Open edX as LTI tool consumer settings: how to set key-secret pairs globally per edX instance?

[Andreas Gelever]

Hi!

I am developing a tool provider for integration with Open edX.

I've got a couple of questions regarding Open edX's LTI support:

1) How should my tool provider reserve key-secret pairs: one key/secret pair per open edX installation (one pair per installation) or per course within a single installation (many pairs per installation)? I'am asking because I failed to find any globally applicable settings in Open edX UI (maybe it is hidden somewhere in django admin tool, no idea?). So now I am only able to create  passports per course just like it is explained in the docs. If I only have one pair per installation - I am forced to irrationally duplicate key-secret pairs (passports) in each course that wants to support LTI integration. 

So what is the correct approach?

2) Which versions of LTI are supported by open edX? I just learned that the current supported version is V1.1.1, that v. 2.0. was not successful and that V 1.3 is about to be released by IMS.

So my question in this regard is:

Does open edX team have any plans in the future to support any higher version than the current V 1.1.1 of the specification (and should I be prepared to support them in my TP)?

Thank you.

[om...@noderabbit.com]

Hi Andreas,

Some of your questions are directed to the edX team, which I'm not part of, so I'll answer the other questions.

> 1) How should my tool provider reserve key-secret pairs: one key/secret pair per open edX installation (one pair per installation) or per course within a single installation (many pairs per installation)? I'am asking because I failed to find any globally applicable settings in Open edX UI (maybe it is hidden somewhere in django admin tool, no idea?). So now I am only able to create  passports per course just like it is explained in the docs. If I only have one pair per installation - I am forced to irrationally duplicate key-secret pairs (passports) in each course that wants to support LTI integration. 

By default, in Open edX, you have to enter the passport for each course. However, the provider, can provide a single key for all of the courses.

If this is really a painpoint, then I suggest that you try the Configurable LTI XBlock developed by https://www.fun-mooc.fr/.

> 2) Which versions of LTI are supported by open edX? I just learned that the current supported version is V1.1.1, that v. 2.0. was not successful and that V 1.3 is about to be released by IMS.

As far as I can tell, the Default LTI Consumer XBlock only supports a subset for LTI 1.0 (aka LTI1p0).

> Does open edX team have any plans in the future to support any higher version than the current V 1.1.1 of the specification (and should I be prepared to support them in my TP)?

I personally, wouldn't be worried about it. Despite being under active development, rolling out such feature would take a lot of time and you usually can still use the LTI1p0 when available.

Best regards,

[Andreas Gelever]

Thank you for explanation!

I've got one more question regarding query parameters that Open edX sends in the launch request:

Is it configurable? Can I add more parameters to be sent to TP by default?

Specifically, by default edX sends only user's e-mail (provided it is set at the LTI item composition stage):

lis_person_contact_email_primary=us...@school.edu

Can I configure edX to send more LTI recommended parameters like:

lis_person_name_given=Jane
lis_person_name_family=Public
lis_person_name_full=Jane Q. Public

I realize that as per LTI v 1.1.1 specification a lot of useful parameters are either optional or recommended, but still I wanna keep track of the users in TP  and somehow identify them.

Maybe there is another way to identify users within TC-TP session?

Thank you once again!

P.S. The parameter user_id is also recommended which means I can barely rely on it either, despite I see that edX sends it without any adjustments for now. 

From LTI specification: "Uniquely identifies the user. This should not contain any identifying information for the user. Best practice is that this field should be a TC-generated long-term “primary key” to the user record – not the “logical key". At a minimum, this value needs to be unique within a TC. This parameter is recommended".