When is a user not a real user?

It is not an uncommon feature of LMSs to allow a user to assume an alternative role to preview content within the system. The most obvious example of this is when a teacher is able to view their course as if they were a student. When a teacher does this they can often attempt the quizzes they have set up to make sure they work. Such quiz submissions would, however, not normally be included when calculating class statistics as they do not represent the work of an actual student on the course. So what happens if this quiz tool happened to be connected to the course via LTI?

LTI is a terrific way of securely passing a user to a third-party application without the need for it to have been pre-provisioned with user accounts; it can just register new users on-the-fly when they first launch. Thus, tools typically rely solely on the data being passed, which can include the user's role(s) within the course (context) from which they have launched. The most common roles sent by an LMS would be for Instructors, Teaching Assistants, Learners and Administrators. These roles represent the privileges for that user in that context at that time - they provide no information about whether they are permanent or transitory. For example, a teacher who is previewing their course as a student and follows the LTI quiz link would probably be passed through with a role of Learner (because that is their current mode of interaction). However, there is nothing which would indicate to the quiz tool that this is not a real student and, therefore, their results may be best excluded from the course statistics. (In some cases the name of the user may provide some indication, but this is LMS-specific and subject to change over time.) That is, until now.

A new role has been added to the LTI vocabulary which, when included in a launch, indicates that all (or some) of the user's other roles which were passed are not permanently associated with the user. The tool can make use of this information or simply ignore it, as with any other role it does not recognise. But it does allow the quiz tool to exclude the user's results from the course statistics should it wish to do so. Similarly, it allows tools to display lists of students which do not include "preview" accounts. There are many tools for which this information is not very useful, for example, if LTI is just being used to authorize access to a resource. However, for those cases where a tool would behave differently if they knew the user was just acting temporarily in a different role, then this new role is an important addition. You may think that having a single preview user mixed up in a list of students for a course would not make a huge impact. But, for example, in recent releases of Blackboard Learn 9, it is possible for a new student account to be created every time a teacher enters the preview mode (indeed this is the recommended setting). Hence, it could very easily lead to a large number of additional students appearing to a tool and they would not know that these users had subsequently been deleted in Learn 9.

So how exactly does this work? For an LMS there is one small change. The launch data would be prepared in the normal way, including the roles parameter which lists all the roles for the current user. However, it should then ask itself the question: "if I were asked for a list of users with each of these roles would it always include this user"? If the answer to this question is "no" then the additional role of urn:lti:role:ims/lti/Transient should be added to the roles parameter. Thus, when a teacher is previewing a course as a student their roles parameter might have a value of Learner,urn:lti:role:ims/lti/Transient (the order of roles does not matter). Similarly, if a system administrator was accessing a course for which they were not formally enrolled, their roles parameter might have a value of Instructor,urn:lti:sysrole:ims/lis/SysAdmin,urn:lti:role:ims/lti/Transient. Note the additional role is included here even though the user is a permanent system administrator, the Instructor role is only temporary. That is, the urn:lti:role:ims/lti/Transient role should be added to the roles parameter whenever one, or more, of the user's roles is temporary (for this launch/session only). The fact that no role may ever be permanent and could be removed or changed is not the issue here; it is the question of whether a role will automatically be revoked from a user at the end of a session which is what this feature is seeking to capture.

If a tool receives a launch from an LMS which supports the transient role, then it may find it being included in the roles parameter. Its presence should not break existing launches because a tool should be ignoring any roles which it does not recognise (this is guaranteed to be the case for certified tools). But if a tool would like to behave differently for such users (in whatever way is appropriate for their application) then it can now inspect the roles parameter for the new role and respond accordingly.

Note that references to "LMS" in this section should be read as referring to any type of LTI tool consumer; this new feature is not limited to LMSs.