Design issues
Identity values
The two main objects for which an identity value may be required are:
- resource link (resource_link_id)
- user (user_id)
These ID values are guaranteed by the tool consumer to be unique; hence, when supporting multiple tool consumers, they should be combined with the consumer key to provide "globally" unique IDs. Note that the user_id parameter is not required by the LTI specification and so may not be received. The user_id parameter should also be an opaque value, typically an internal database key; if you need to match a user account with existing data then look for the optional lis_person_sourcedid parameter (a similar LIS parameter may also be passed for the context: lis_course_section_sourcedid). Be very wary of using a value such as email address as an identity value for a user - not only may it not be unique, but it also may not be a trusted value in the sense that the tool consumer may allow users to edit this value themselves.
Roles
The typcial roles which a user might be given are:
- Learner
- Instructor
- Teaching Assistant
The role name may be prefixed with "urn:lti:role:ims/lis/" so, for example, urn:lti:role:ims/lis/Instructor is equivalent to Instructor. (See Appendix A.2 of the LTI specification for a complete list of permitted roles.) Note that a user may have more than one role, multiple roles are separated with commas.
Data persistence
Which values passed in a launch are actually required and which should be saved? Wherever possible you should aim to rely on as few of the launch parameters as possible; very few are actually required by the LTI specification. Default values can be used for some missing parameters; e.g. a user's name. There are also legal considerations about the passing of personal data to external systems which may restrict was is made available from a tool consumer. Since each launch contains the same parameters, there may be no need to keep a local copy which may also help with satisfying legal requirements on personal data.
