LTI 1.3 "sub" not the same as 1.1 "user_id"?

[jborrebach]

My team is working on our LTI 1.3 tool implementation.

I’ve been running some test scenarios where our LTI tool is “upgraded”. That is, I launch an LTI link in a test course using a 1.1 tool, then replace that tool with a 1.3 tool associated with the same domain, and launch that same link again.

I think I’m seeing that the “sub” claim in the LTI 1.3 launch doesn’t match the “user_id” parameter in the LTI 1.1 launch. With the other platforms we're integrating with, these terms are the same.

• LTI 1.1 user_id: 5b57828bb93b88119cc48a4c5070d3207d69366e

• LTI 1.3 sub, for same user: 7bb30dfe-bfd8-4872-86c1-3e50718e9f51 

Am I observing this accurately, and if so, is this the expected behavior? I know the IMS specs describe the possibility of it.

And if so, then do you have a recommendation for how we could obtain the user’s “old” user_id in a 1.3 launch?

I believe I’m also seeing a different resource link ID for the same assignment. We don’t actually use that info in our system, so that doesn’t matter to us though.

[pklove]

I think this is the same issue as in this thread: https://community.canvaslms.com/thread/38451-names-and-roles-provisioning-userid 

Something there might be of interest/help.

[jborrebach]

Thanks, Peter! Yes, that answers my question.

If anyone else has this same question -- the short answer is, yes, an LTI 1.3 launch will send a different user_id than an LTI 1.1 launch from the same user + Canvas instance.

Here's the reply from Jesse Poulos on the other thread that gives the full answer, and how to obtain the "old" user_id in a LTI 1.3 launch:

Due to the global nature of LTI 1.3 in identifying users, Canvas had to add a new identifier for users. This id is the uuid format you are mentioning and is unique for a user globally, whereas the LTI 1.1 id was scoped to an account.

There is a way, using custom_fields, to retrieve the account-scoped user id that can then be used to map a user's new id in your database. These custom_fields would look something like `old_user_id: $vnd.instructure.User.current_uuid` in your custom fields declaration. If you need to map users who have been merged, you could also include something like `current_context_old_user_id: $vnd.instructure.User.uuid` in your custom fields declaration. The combination of these two fields should be sufficient to map a launched user to any given user in a context that may already exist in your database.