User Management

Stopgap: Require all LTI users to have an account on the OpenEdX installation

This does not meet the requirements from the MVP spec, but it will allow us to make some initial progress while we iron out the details of the user model. For now, we can require that students first go through the sign-up process to get regular edX accounts, and then on the first launch we associate their LTI user_id with that account. There are two possible paths:

1. The user has an existing cookie for the edX installation. In that case we can link IDs behind the scenes with no additional user actions.
2. The user does not have a cookie. We can redirect to the login/account creation page, and have the user log in. At that point we link the accounts.
   

While this will be a short-term solution, much of the code that we will use for this functionality will be re-usable later when we come to link anonymous and edX accounts. We may also want to enable this behavior as a course-level option long-term, allowing instructors to require that students have an edX account (assuming that is a valid approach at their institution).

Requirement: Anonymous ID linked to the campus LMS identity.

This requirement implies that we may need to create a second type of user in edX. A user who signs up through the edX registration process has at minimum the following attributes:

1. Email address
2. Full name
3. Public user name
4. Country
5. Password

The user has also agreed to the ToS and the honor code.

A user who enters the edX site through LTI is not guaranteed to have any of these things. There are no required user-specific attributes in the LTI 1.2 spec (even the user ID is only recommended). We can of course require a minimal set before we will allow a user to access edX (see the LTI launch page), but since one of our other requirements is to allow for a launch with no Personally Identifiable Information (due to various national privacy laws), we can be certain that there are circumstances in which we will not have this information available.

Our LTI users will either have some empty attributes or some automatically generated. In either case, we will have to figure out where the existing edX code assumes that a user has a particular attribute and make sure that it will continue to work properly without one. An example would be the discussion forums - if our user has no public user name, we must either ensure that we have a generated user name (which wouldn't be particularly useful to forum viewers), or make sure that the code can handle an empty user name.

Topic: Defining a unique login ID (e-mail) for an LTI user

Requirement: Identity linking between edX account and campus LMS account

We would like to allow a student with an existing edX account to associate their anonymous account with their complete profile. There are two levels of linking:

1. Maintain separate edX and anonymous accounts, but create a connection between them so that students (and researchers) can track their activities together.
2. Merge the anonymous and edX accounts, so that a user always works in the context of the same account regardless of how they get into the edX system.

Some considerations here:

• Any given user may have accounts on multiple campus systems (so the mapping is one-to-many, rather than one-to-one).
  • Do we want to support a user having multiple edX accounts (making the mapping many-to-many)?
• A student may end up using many different Open edX installations - one class may be on edx.org, another on edge.edx.org, etc.
  • This should be transparent to the user, given the requirements in the MVP document
  • Transparency is bad in this case, since the student may be confused as to when accounts can be linked.

Cookies

If a student has multiple identities on a given system, we will have to account for the different possibilities when it comes to cookies. Ideally, we would like to minimize the amount of logging in and out that a student must do.

The first time a given student accesses the course via LTI, there are three possible cookie states:

1. No cookie. We create a new anonymous account as described above.
2. Existing edX account. There are three things we can do here:
   1. Log the student out and create a new anonymous account.
   2. Associate the LTI user_id with the existing edX account.
   3. Create a new anonymous account and link it with the existing edX account.
3. A cookie related to some other anonymous account. 

The third case could happen if the student accesses the edX installation through two different campus systems (maybe the school uses Canvas for some classes and Blackboard for others, or the student takes classes at two different schools). This is a trickier case to deal with, since we will first have to define the relationship between anonymous and regular edX accounts.

There is also the question of what happens the next time the student visits the regular edX site after having been logged in using an anonymous account. In this case, it's possible that their browser still has a cookie from their LTI-launched session, and so they're not able to access their regular courses. At first glance this seems hard to solve for all cases - we need the cookie to exist in order to navigate between pages, and we don't have a bullet-proof way to ensure that a student is logged out after the LTI session.

Requirement: Batch upload of student data

A course admin should be able to create edX accounts for all students in a single batch operation, simplifying the identity mapping process.

The admin must know the user_id that the LMS will send to edX so that edX can identify a user as a member of the uploaded group. This isn't a given - the LTI spec says that a user_id should not contain any personally identifying information and may be generated internally by the tool consumer. The instructor may not have access to the ID that will be sent. In order to use this mode, we may have to require additional information in the LTI launch that provides some identifier that is available to the instructor.

If we enable bulk user creation and grouping, does that mean that all students must be pre-enrolled?

A course admin should be able to define groups among those uploaded users

We'll have to define some format for this data upload. 

If a student joins the class after the bulk upload has occurred, what (if any) group should they be placed in? Obvious options would be to let the instructor define a default group, or to have the students be members of no groups.

Open Questions

• Can anonymous users interact as fully as regular users? Does it make sense for LTI users to post on discussion boards, see grades, etc?