LTI Provider Knowledge Transfer

Notes from meeting with Philip McGachey on Jan 27, 2016

edX as an LTI Provider
- Initially because the Harvard Provost wanted to bring edX content back to Harvard
- Development work between Jan -> June/July 2015
- For on-campus integration
    - largest course is on the order of 400 students

Basic LTI version 1
- basic web protocol
- provide a server somewhere, like edX
- redirect user via POST to a well-known endpoint
- POST carries a JSON blob
- extensible
- basics:
  - content
  - user identity - hash of the user-id in teh context of edX
  - user role
  - oauth signature

- setup LTI launch URLs
- map user's identity to edX account
- mapping between LTI user id and edX user id
- idea is that the user coming through Canvas doesn't see an edX login page
- interest in working group to use LTI to login
  - that turned into the SSO work

LTI version 1.1
- adds ability to pass grade back to the original system
- when a grading event happens at edX, we pass it back

LTI version 2
- still very early in terms of people actually using it

Canvas
- harvard.instructure.com/courses/
- Canvas (LTI consumer) is set up with user modules (no grades) and assignments (grades)

Which edX content?
NOT:
- discussions - username kind of wacky - so not really great for consuming
- ORA - kinda works, but email address issues for notifications
- edX video player is much ahead than what's there in Canvas
- edX problem types are much more automated
- drag and drop is interesting

openedx.lti.harvard.edu
- All courses are run only through the LTI interface
- Users have randomly generated edX user ID
- A single canvas course will have modules from both edX course and from canvas
  - discussions are not edX discussions, but from canvas
    - can have avatars and correct usernames

- Could link directly to edx.org, but professors wanted to keep things in-house

- User profile/model mapping
  - LTI APIs may not always have all the user information
  - It depends on how that particular launch of LTI was configured

Segmenting Content
- Can do it at the vertical level or at the subsection level

Testing
- LTI spec is pretty stable
- xBlock developer guidelines
  - some xBlocks may not work through LTI
      - for example, if it assumes all users have email addresses
          - Note: this is not just an LTI issue.  Many mobile users do not actively use email.
  - code that breaks out of an iFrame, can break the canvas frame (possibly includes 500 errors)
- Test harness
  - Need a mock LTI consumer

Code

• lms/djangoapps/lti_provider
• Usage ID
  • currently, harvard exports the course to OLX -> then, they have a custom tool to get the Usage IDs
  • there's an OSPR to get the LTI_URLs from the Course Blocks API
• LTI and LIS are standards from the same body.  LTI is now used, while LIS isn't.
  • LIS for managing student information.
• Only used on Edge right now, not on Prod.  Probably not enabled on Prod.
• OAuth timestamp and nonce  - Nonce not implemented yet
• store_outcome_parameters
  • setting up grade model
  • entry per user per lti graded component
  • lis_result_sourced_id (optional)
    • explicitly set up in Canvas, rather than assume that each edX graded component is graded in Canvas
    • allows course teams to use graded components as ungraded components (by dropping this id)

Models
        LTIConsumer
            - consumer_name, consumer_key, consumer_secret are always there
            - instance_guid may not be there for all consumers

        OutcomeService
            - service for sending back the grades
            - same type of URL for our LTI consumer

        GradedAssignment

• • a row in the database for every user and every usage_key
    • cannot deterministically compute the lis_result_sourcedid based on a user/usage_key URL template
    • because the LTI spec is vague
    • but since there aren't that many users per LTI course, it shouldn't be a scalability issue for now.
    • we should think about ways to garbage collect old outdated rows.
  • the outcome callback url is only stored once per consumer
    • LTI spec says this should never change, but it could.
    • storing once ensure if it did change, old records wouldn't become stale.
    • doesn't handle the case where a single consumer uses multiple outcome urls (which edX as LTI consumer might do)

        LtiUser
            - mapping between edX user and LTI user
            - a blank User profile is created

User
        - Automatically "switch_user" if the LTI user associated with the request session has changed
            - This happens if the user is switched on Canvas (from staff to student, for example)
        - Automatically create new users until no email/username collision

        - Possible issues with LTI users and non-LTI users within the same course (currently LTI users are not enrolled)
            - May not be a real use case
            - But for now, we're not treating them as regular users
            - Enrolling LTI users
                - but only if we are treating them as regular users

Tasks

• signal for scoring events from ORA and scoring service
• Need to have some wait
  • since the view is part of the transaction, and the data model would not have been updated
  • we don't want to send intermediate results (if someone is in the middle of answering multiple questions)
    • note that this was the main reason that Beth asked for a 15 minute delay on the celery task
• Version numbers are there to help with the race condition

    - LtiBackend
        - to implement our own django authentication backend

Multi-tenancy
- Access is all or nothing.
- ALL LTI consumers on Edge can access ALL courses on Edge.
- The user's browser sees all the LTI information, but NOT the secret key.  So they can't change the parameters.

A/B testing
- Users will automatically get assigned to their randomized block.
- However, at Harvard, course teams are recommended to use Canvas' (custom) A/B testing tool.

Analytics
- In progress: Merging Canvas and edX tracking logs, with mapping of edX and Canvas accounts.

Docs
- Conformance test
    - all the functionality is there
        - perhaps only the grade passback

Open PR
    - someone wants to send in more optional parameters
    - related to grade passbook

Questions
- Getting LTI consumer key pair from whom?  It used to be Beth?
- Can we update the edX LTI consumer to also send the edX server address?  Since LTI user-ids are not globally unique.
- Remove code "immediately break out of an iframe if coming from the marketing site" - that causes issue for LTI.
- Remove 'roles' and 'context_id' from REQUIRED_PARAMETERS list.
- Is the lack of access control an issue?  "All LTI consumers on Edge can access any course on Edge - including microsites.
- For OAuth spec compliance, we need to implement the Nonce.  It was originally de-prioritized since the use case requirement wasn't clear if needed.
- Certificate generation will break since it assumes the user has a created Profile.
    - But it looks like the LTI code now creates a User Profile - though only an empty shell
- edX as an LTI consumer won't work with edX as an LTI provider
    - because it uses multiple source urls for grades
- Whether to open up edX to allow LTI users to enroll in course.
    - only because the existing reports look at just enrollments
        - perhaps create fake enrollments
    - assuming that the LTI consumer is the system of record
        - don't want to open up a can of worms.  will this affect analytics? demographics?  other reports or functionality?

- Should LTI provider functionality be the purpose of using content across LMSes, or edX as a content library
    - What is the edX user model?
    - What is an LTI user?
    - What is an SSO user?

• edX LTI as Consumer should set tool_consumer_instance_guid
  • it is likely that edX's public-ish key is used in other LTI providers (like edX) and can't be changed.  It is also possible that when it starts providing this it will break things for old launch configurations.