Selecting a User ID in LTI®
Most tool providers will want to record activity against individual users and hence will need some way to uniquely identify each user when a launch request is received. So what parameters should be used as a unique user identity value? Well, the answer to this question is that it depends!
The PHP LTI Tool Provider class library implement 4 choices (or scopes) for creating unique IDs:
- Global: just use the user_id parameter;
- Consumer: combine the consumer key with the user_id parameter;
- Context: combine the consumer key with the context_id and user_id parameters;
- Resource link: combine the consumer key with the resource_link_id and user_id parameters.
Each of the choices is useful in different situations.
Since the user_id parameter is only guaranteed to be unique for the same tool consumer, the Global choice only makes sense if the tool provider is dedicated to a single tool consumer (e.g. a local installation for a University) or if it is known that the sets of user_id values from the different tool consumers do not intersect. This is not a choice I would recommend; even if only a single tool consumer is expected to be supported, you never know if this might change in the future - for example, an alternative VLE is made available within the University.
The Consumer choice guarantees to provide you with a unique ID for each user within the tool provider system. However, its use does mean that the same user ID is used for launches from all the resource links added in the tool consumers. Thus, there is a possibility that users following one resource link, may be able to access content linked from another resource link, thereby bypassing the authorisation process provided by the tool consumer. For example, a student may have been unenrolled from a course in the VLE and, therefore, no longer have access to the resource links in that course. If launching from another course allows them to access the end points of these resource links, then the tool provider has effectively provided a back door for users to access resources which they should have been disconnected from. Some solutions to this problem may be available to you. For example, if you control the code for the tool provider application, you can prevent users from switching to a different resource after a launch. Alternatively, if the tool consumer supports the unofficial memberships service, the list of users for each resource link can be updated on a regular basis (e.g. nightly) so any impact will only be short-lived.
The Context choice is similar to the Consumer choice (see above) except that it implements an ID value which is only unique within a context (e.g. a course). If all resource links within a context are always available to all users enrolled in that context, then there is no issue about providing a back door method for accessing resources. However, if access to some resource links might be restricted to a subset of the enrolled users (e.g. via a conditional release mechanism) then this choice could provide a way for users to bypass the authorisation implemented by the tool consumer (for which similar solutions as discussed above could be implemented).
An implementation of LTI should recognise that when a launch request is received, all this tells the tool provider is that the user (as identified by the user_id parameter) from the specified tool consumer is entitled to access the specified resource (as identified by the resource_link_id parameter). It says nothing about the user's current entitlement to access any other resource links from the same tool consumer or context, even if the user has previously been able to do so. Hence the Resource link choice for creating user ID values is the closest fit to the expectations of the LTI specification. A downside of implementing this choice is that it means that a separate user account will be created in the tool provider for every combination of user_id and resource_link_id parameters (and for each consumer key). Thus, if a course has 5 links to the tool provider, a user following each of these links will have 5 separate user accounts created in the tool provider. But if you do not have control over the tool provider code then this is a sure way of preventing a user from bypassing the authorisation implemented by the tool consumer - each user will, by definition, only have access to a single resource; accessing other resources must be achieved via a separate user account (accessed by launching via a different resource link in the tool consumer).
So there are choices of how to implement a user ID when developing a tool provider LTI integration and that choice will depend upon the circumstances of each case. Hopefully the above discussion will help you identify the one which is most appropriate to your case, and appreciate some of the pro's and con's in making this choice.
1EdTech provides numerous resources for enabling your application to use LTI. Once you complete your LTI development you should apply for 1EdTech certification. Certification testing is available to 1EdTech Members and will ensure that your products utilizes LTI correctly.
