2      Overview of Tool Management Use Cases

Description of use cases included in the LTI 2 specification

3.     Component Model

Description of the various components used in LTI 2

4.     Tool Management Use Cases

Descriptions of each of the LTI 2 use cases

5.     Information Model

Description of the classes and schemas for the LTI information model

Use Case Title:

Deploying a Tool Proxy within a Tool Consumer

Use Case Local ID:

LTIv1-01

Brief Description:

This use case describes the basic steps involved in the deployment of a Tool Proxy within a Tool Consumer.  

Level:

Summary

Actors:

TC Administrator, Tool Provider system, Tool Consumer system

Preconditions:

There are three different ways to initiate this workflow:

• By submitting the Tool Proxy Request form 
  (see Use Case LTIv1-02)
• By participating in the workflow for importing an archive that contains a Tool Proxy Locator
  (see Use Case LTIv1-03), or
• By choosing to deploy a new version of a Tool Proxy that is already registered with the Tool Consumer
  (see Use Case LTIv1-11).

In all three cases, the workflow starts with the TC Administrator interacting with a user interface in the Tool Consumer system. This use case picks up immediately after that initial interaction.

Basic Flow of Events:

1.       Launch Deployment UI.   The TC Administrator’s browser (a.k.a. User Agent ) sends a ToolProxyRegistrationRequest to the Tool Provider’s Deployment URL, and hence the browser  navigates into the Deployment UI within the Tool Provider system.  The ToolProxyRegistration­Request is sent to the Tool Provider via the automatic submission of an HTML form, as described in the LTI Messaging Framework specification [LTI, 12 MSF].

2.       Get Tool Consumer Profile.  Among other things, the ToolProxyRegistrationRequest includes the URL for accessing the Tool Consumer Profile.  The Tool Provider obtains the Tool Consumer Profile from this URL by appending the lti_version query parameter to the URL and submitting an HTTP GET request.  The Tool Consumer will return the JSON representation of the Tool Consumer Profile in the response using the “application/vnd.ims.lti.v2.ToolConsumerProfile+json” media type.

3.       Interact with Administrator.  The Tool Provider interacts with the administrator.  The LTI standard does not define the details of this step.  Here are some typical interactions that may occur within the Deployment UI:

1. Tool Provider requires the administrator to authenticate himself or herself by submitting an access code that was received out of band.
2. Tool Provider requires the administrator to enter a Customer ID.
3. Tool Provider requires the administrator to select the particular Tool that is to be deployed.
4. Tool Provider allows the administrator to choose the set of tool features that should be enabled[1].
5. Tool Provider displays to the administrator the data access requirements of the Tool, based on the selected feature set.[2]
6. Tool Provider requires the administrator to submit payment for the selected Tool.

4.       Submit.  When all the interactions are complete, the administrator makes a final submission to the Tool Provider.

5.       Validate the Tool Consumer Profile.  The Tool Provider examines the Tool Consumer Profile that was obtained in Step 2 and confirms that the capabilities and services offered by the Tool Consumer are compatible with the needs of the Tool.

6.       Register the Tool Proxy.  The Tool Provider constructs a Tool Proxy and submits it to the the appropriate REST endpoint within the Tool Consumer.  The Tool Provider discovers this endpoint by inspecting the Tool Consumer Profile.  This operation allows the Tool Provider to convey the following information to the Tool Consumer:

a.       Tool Profile

b.       Shared Secret that will be used to secure subsequent communications between the two systems

c.        Set of services and operations which the Tool Provider requires.  Typically, this will be a subset of the collection of all services offered by the Tool Consumer as declared in the Tool Consumer profile.

d.       A list of TC capabilities that the TP wishes to utilize.

At this point, the Tool Proxy is registered with the Tool Consumer, but it is not enabled.

7.       Redirect back to the Tool Consumer . The Tool Provider redirects the User Agent back to the Tool Consumer system at the URL specified by the launch_presentation_return_url parameter posted with the ToolProxyRegistrationRequest.  To this URL, the Tool Provider appends the following HTTP query parameters:

status=success
tool_proxy_guid=<globally unique identifier for the Tool Proxy>

where the value for the tool_proxy_guid parameter is given by the return value from the registerTool operation.  Typically, this action redirects the administrator’s browser to the Tool Console within the Tool Consumer system where the Tool Proxy can be made available (see the next step).

8.       Make Tool Proxy Available. Before the Tool Proxy can be used within the Tool Consumer, it must be placed into the “available” state, as described in Use Case LTIv1-04.  The Tool Provider will not have access to any Tool Consumer services until such access has been authorized by the administrator when the tool is enabled. 

Alternative Flows:

A.      Customize Options based on Tool Consumer capabilities

At Step 3, the Tool Provider may customize the interactions with the Administrator based on the capabilities announced in the Tool Consumer profile.  For example, if the Tool Consumer does not offer a web service for pushing scores into its online gradebook, then the Tool Provider should not offer this feature as an option.

B.      Tool Consumer Profile validation fails.

At Step 5, the Tool Provider may determine that the capabilities and services offered by the Tool Consumer are not sufficient to support the needs of the Tool.  In this case, the following actions occur:

1. Tool Provider displays an error message to the administrator explaining why Tool Proxy deployment cannot be completed.
2. Administrator clicks some control (such as a button) within the Deployment UI to cancel the deployment process.
3. The Tool Provider redirects the administrator's User Agent to the Registration Completion UI.  The Tool Provider appends the parameter status=failure to the redirect URL.

C.      Custom URL for each Tool

In some cases, the Tool Provider may define a different deployment URL for each type of Tool.  In this case, there is no need for the administrator to select a tool at Step 3, and the Tool Provider may be able to validate the Tool Consumer Profile immediately after receiving it in Step 2.

D.      Query Parameters in the Deployment URL

If the Deployment URL contains query parameters, the Tool Consumer parses these parameters and adds them as POST parameters in the HTML Form that represents the ToolProxyRegistrationRequest.  The query parameters are stripped from the Deployment URL, and the resulting URL (without the query parameters) is used as the action attribute of the HTML Form that is auto-submitted in Step 2.

E.      Early Validation of Tool Consumer Profile

The Basic Path indicates that the Tool Provider validates the Tool Consumer Profile immediately prior to submitting the Registration Request.  However, the Tool Provider may choose to validate the Tool Consumer Profile at other points within the workflow.  For example, the TP may validate the TC Profile upon receiving it at Step 2, and it may abort the entire process immediately if the TC does not offer some minimal set of capabilities and services.

F.       No interaction with TC Administrator

In some cases, it may not be necessary for the Tool Provider system to interact with the TC administrator.  For example, the Tool Provider might offer only one Tool with no configuration options. Or the details might be encoded in the Deployment URL as query parameters. Thus, in some cases it may be possible to skip Steps 3 and 4.

Postcondition:

The Tool Proxy is deployed to the Tool Consumer but not enabled.

Use Case Title:

Deploying a Tool Proxy via the Tool Proxy Request Form

Use Case Local ID:

LTIv1-02

Brief Description:

This use case extends the Basic Tool Proxy Deployment process by defining one way to initiate the deployment workflow.  In this use case, an administrator initiates the deployment of a Tool Proxy by submitting the Tool Proxy Request Form.

Level:

Summary

Actors:

Tool Consumer Administrator, Tool Consumer system

Basic Flow of Events:

1.       Obtain Tool Deployment URL.  The administrator obtains a Deployment URL from the Tool Provider.  This is the URL that will be used to launch the  Deployment UI.  The LTI standard does not define how the administrator acquires the Deployment URL.  It may be delivered via email, or by any other means.

2.       Submit  Tool Proxy Request Form.  The Tool Consumer implements a Tool Proxy Request Form which contains an input field where the administrator can enter the Deployment URL.  The administrator navigates to this form within the Tool Consumer, enters the Deployment URL, and submits the form. 

3.       Generate ToolProxyRegistrationRequest.  The Tool Consumer responds to the submission of the Tool Proxy Request Form by generating a ToolProxyRegistrationRequest.  In this use case, the vendor_code, tool_code, and tool_version attributes of the request are not defined.

In accordance with the LTI Messaging Framework [LTI, 12 MSF], the ToolProxyRegistrationRequest is rendered as an HTML form and auto-submitted to the Tool Provider. The  value for the action attribute of the form is given by the Deployment URL that was submitted in Step 2.  Thus, when the form is auto-submitted, it will be posted to the Tool Provider at the Deployment URL.

4.       Use Basic Tool Proxy Deployment Process. The remainder of this use case follows the Basic Tool Proxy Deployment sequence, see Section 4.1.1.

Since the tool_code and tool_version are not defined in the ToolProxyRegistrationRequest, the Tool Provider will need to identify the particular Tool Proxy that is being requested by some other means.  The Tool Provider may use either of the following methods:

• The Tool Provider may infer the Tool Proxy from the Deployment URL.  In other words, the Tool Provider might use a different Deployment URL for each version of the Tool Proxy.
• Alternatively, the Tool Provider might require the administrator to choose a particular Tool Proxy as one of the activities that occurs within the Deployment UI. (See Step 3 of the Tool Proxy Deployment use case.)

Alternative Flows:

A.      Customized Tool Consumer Profile

At Step 2, the Tool Proxy Request Form may allow the TC Administrator to limit the set of services and capabilities that will be offered to the Tool Provider.  In this case, the Tool Consumer generates a customized Tool Consumer Profile which advertises only the selected services and capabilities.  In this case, the ToolProxyRegistrationRequest generated at Step 3 will contain the URL for the customized Tool Consumer Profile. 

Use Case Title:

Making a Tool Proxy Available

Use Case Local ID:

LTIv1-04

Brief Description:

Describes the sequence of events that occurs when an administrator makes a Tool Proxy available within the TC system.

Level:

Summary

Actors:

·         Tool Consumer System Administrator

·         Tool Consumer Runtime

·         Tool Provider

Preconditions:

·         Tool Proxy has been deployed to the Tool Consumer

·         Tool Proxy is initially in the unavailable state.

Basic Flow of Events:

1.       Request Tool Proxy state change.  The Tool Consumer System Administrator navigates to the Tool Console in the Tool Consumer system, and he or she submits a request to change the state of the Tool Proxy to “available.”

2.       Display Security Warning. The Tool Console displays a warning about the security implications of making the Tool Proxy available.  For each type of business object (Person, Course Section, Membership, Grades, etc.),  the Tool Console discloses the ways in which the Tool Provider system might manipulate these objects.  As a general rule, the TC should not merely report the specific web service operations that the TP will be authorized to access since this information may not be meaningful to the typical administrator.  Instead, for each type of business object, the Tool Console should disclose whether or not the Tool Provider will be able to create, read, update or delete that entity. 

These details are derived from the security contract.  For example, suppose the security contract declared that the Tool requires access to the readPerson operation of the LIS Person Manager and all the operations of the LIS Result Manager.  In this case, the Tool Console should warn the administrator that the Tool will be able to read directory information about users and will be able to read and write entries in the gradebook.

This disclosure step is a best practice; it is not required for compliance with the LTI standard.

3.       Persist Tool Proxy state in Tool Consumer.  The change to the Tool Proxy state is persisted in the Tool Consumer system.   Once the Tool Proxy is available, Instructors and Course Builders can enable the Tool Proxy in any course section within the Tool Consumer (see Use Case LTIv1-07).

Postcondition:

Tool Proxy is in the available state.

Use Case Title:

Making a Tool Proxy Unavailable

Use Case Local ID:

LTIv1-05

Brief Description:

Describes the sequence of events that occurs when an administrator makes a Tool Proxy unavailable within the TC system.

Level:

Summary

Actors:

·         Tool Consumer System Administrator

·         Tool Consumer Runtime

·         Tool Provider

Preconditions:

·         Tool Proxy has been deployed to the Tool Consumer

·         Tool Proxy is initially in the available state.

Basic Flow of Events:

1.       Request Tool Proxy state change.  The Tool Consumer System Administrator navigates to the Tool Console in the Tool Consumer system, and he or she submits a request to change the state of the Tool Proxy to “unavailable.”

2.       Persist Tool Proxy state in Tool Consumer.  The change to the Tool Proxy state is persisted in the Tool Consumer system.   At this point, instructors and course builders will no longer be able to add the Tool Proxy to new course sections within the Tool Consumer system. All existing Tool Proxy Bindings for this tool must behave as if they have been explicitly disabled as described in use case LTIv1-08.

Postcondition:

The Tool Proxy is in the unavailable state.

Use Case Title:

Enabling a Tool Proxy in a Learning Context

Use Case Local ID:

LTIv1-07

Brief Description:

Instructor or Course Builder enables a Tool Proxy in some learning context.

Level:

Summary

Actors:

·         Instructor or Course Builder

·         Tool Consumer (TC)

Preconditions:

The Tool Proxy has been registered with the Tool Consumer.

Basic Flow of Events:

1.       View available Tools. Instructor or Course Builder navigates to the Binding UI within the learning context.  From this interface, the user can browse or search for all available Tool Proxies.

2.       Enable Selected Tool. Instructor or Course Builder chooses to enable a particular Tool Proxy within the Learning Context.  The TC creates a Tool Proxy Binding that relates the selected Tool Proxy to the given learning context, and initializes the binding in the enabled state.

3.      Display links.  If the learning context contains resource links, then those links become active.

Alternative Flows:

A.      Enable an existing Tool Proxy Binding that is disabled

The Basic Flow treats the case where a new Tool Proxy Binding is created.  This effectively adds a new Tool to the learning context.  However, it is possible that the Tool Proxy was previously added to the learning context but was subsequently disabled.   In that case, at Step 2 the Tool Proxy Binding is not re-created but instead its state is merely changed to enabled.

Postconditions:

·         A Tool Proxy Binding has been created and is in the enabled state.

·         Tool Provider may access data associated with the learning context by invoking the relevant web services offered by the Tool Consumer.

Use Case Title:

Disabling a Tool Proxy in a Learning Context

Use Case Local ID:

LTIv1-08

Brief Description:

Instructor or Course Builder disables a Tool Proxy in some learning context.

Level:

Summary

Actors:

·         Instructor or Course Builder

·         Tool Consumer (TC)

Preconditions:

The Tool Proxy has been registered with the Tool Consumer.

Basic Flow of Events:

1.       View Enabled Tools. Instructor or Course Builder navigates to the Binding UI.  From this interface, the user can browse or search for all enabled Tool Proxies within the current learning context.

2.      Disable Selected Tool. Instructor or Course Builder chooses to disable a particular Tool Proxy within the learning context.  The TC persists this change internally.

Postconditions:

·         The Tool Proxy Binding state has been changed to disabled.

Use Case Title:

Removing a Tool Proxy from a Learning Context

Use Case Local ID:

LTIv1-09

Brief Description:

Instructor or Course Builder removes a Tool Proxy from a given learning context.

Level:

Summary

Actors:

·         Instructor or Course Builder

·         Tool Consumer Runtime (TC)

·        Tool Provider (TP)

Preconditions:

Tool Proxy Binding has been created to establish a relationship between some learning context and a given Tool Proxy

Basic Flow of Events:

1.       View Bound Tools. Instructor or Course Builder navigates to the Binding UI within some  learning context.  From this interface, the user can browse or search for all Tools that are bound to the learning context.

2.      Remove Selected Tool.  Instructor or Course Builder explicitly performs an action to remove a selected Tool from the learning context.  TC deletes the Tool Proxy Binding and disables or hides resource links.

Postcondition:

·         The Tool Proxy Binding has been removed from the learning context. 

·         All resource links associated with the Tool Proxy have been hidden or disabled within the context.

Use Case Title:

Updating a Tool Proxy within  a Tool Consumer

Use Case Local ID:

LTIv1-11

Brief Description:

Tool Consumer Administrator applies updates to a Tool Proxy that is currently registered with the Tool Consumer Runtime.  Note that the activities in this use case are similar to the activities that occur in Basic Tool Deployment (Use Case LTIv1-01).

Level:

Summary

Actors:

·         Tool Consumer Administrator

·         Tool Consumer Runtime (TC)

·         Tool Provider (TP)

Preconditions:

·         Tool Proxy has been registered with the Tool Consumer

·         Tool Consumer Administrator has been alerted that an update is available.

Basic Flow of Events:

1.    Initiate the update process. TC Administrator performs an action within the Tool Console to initiate the update process for a selected Tool Proxy.

2.    Send HTML Form. The TC responds by sending an HTML form that contains a ToolProxyReregistrationRequest to the administrator’s browser (a.k.a. User Agent).

3.    Post ToolProxyReregistrationRequest. The User Agent auto-submits the HTML form and thereby posts the ToolProxyReregistrationRequest to the Tool Provider.

4.    Get Tool Consumer Profile.  The TP retrieves the Tool Consumer Profile from the URL specified by the tc_profile_url parameter.

5.    Interact with Administrator.   The TP may optionally interact with the TC Administrator.  The LTI standard does not require any particular interactions, but typical activities may include:

a.       Choosing (or confirming) which version of the tool should be used.

b.       Changing the set of tool features that should be enabled.

c.        Collecting payment (if the license has expired).

6.    Submit.  When all interactions are complete, the Administrator makes a final submission to the TP.

7.    Validate Tool Consumer Profile.  The TP validates the Tool Consumer profile that was obtained in Step 4 to ensure that the services and capabilities offered satisfy the requirements of the tool.

8.    PUT updated Tool Proxy.  TP constructs a revised Tool Proxy and PUTs a JSON binding of the Tool Proxy at the appropriate REST endpoint as declared in the Tool Consumer Profile. As a best practice, the updated Tool Proxy submitted to the TC should contain a new shared secret. 

The TC persists the revised Tool Proxy.  If the Tool is requesting access to a new set of services offered by the TC, then the Tool Proxy should be put into the unavailable state immediately after reregistration. 

9.    Redirect back to Tool Consumer . TP redirects the Administrator’s browser back to the TC at the URL specified by the launch_presentation_return_url parameter from the  ToolProxyReregistrationRequest posted at Step 3.  To this URL, the Tool Provider appends the following HTTP query parameters:

status = success
tool_proxy_guid = <globally unique identifier for the Tool Proxy>

Typically, this redirect action  returns the user to the Tool Console within the TC system where the updated Tool Proxy can be made available (see the next step).

10.  Make Tool Proxy Available. If the security contract has changed,  the TC displays the new set of entitlements that will be granted to the Tool Provider, and it presents the administrator with an option to make the Tool Proxy available again.

Alternative Flows:

A.      No state change

If the security contract has not changed, then the state of the Tool Proxy should not change at Step 8.  In particular, if the Tool Proxy was originally available, it will still be available after reregistration, and in this case Step 10 can be skipped.

Use Case Title:

Upgrading Tool Proxy Bindings

Use Case Local ID:

LTIv1-12

Brief Description:

Tool Consumer Administrator upgrades all learning contexts that are bound to one version of a given Tool Proxy to a newer version.

Level:

Summary

Actors:

·         Tool Consumer Administrator

·         Tool Consumer Runtime

·         Tool Provider

Preconditions:

·         Two versions of the same Tool Proxy are registered simultaneously with the Tool Consumer

Basic Flow of Events:

1.       Initiate the upgrade process. Tool Consumer Administrator navigates to the Tool Console and performs an action to initiate an upgrade from one version of the Tool Proxy to a later version.

2.       Display a list of affected learning contexts. The TC optionally displays a list of the learning contexts (e.g. course sections) that will be affected and offers the administrator an opportunity to abort the upgrade process.

3.       Submit Confirmation. The Administrator confirms that he or she wishes to proceed with the upgrade process.

4.       Update Tool Proxy Bindings. The TC updates the Tool Proxy Bindings for all learning contexts that are currently using the older version of the Tool Proxy so that they now use the newer version.

Alternative Flows:

A.      Instructor upgrades binding

An instructor may upgrade to a newer version of the Tool Proxy in a particular learning context by removing the old version and enabling the new version.  (See 0)

Use Case Title:

Removing a Tool Proxy from a Tool Consumer

Use Case Local ID:

LTIv1-13

Brief Description:

The Tool Consumer administrator removes a Tool Proxy from the Tool Consumer system.

Level:

Summary

Actors:

·         Tool Consumer Administrator

·         Tool Consumer Runtime

Preconditions:

 Tool Proxy has been registered with the Tool Provider

Basic Flow of Events:

1.       Initiate the removal process. Tool Consumer Administrator navigates to a web page within the Tool Consumer system and performs an action to manually remove a selected Tool Proxy.

2.       Disable Resource Links. The TC deletes all Tool Proxy Bindings associated with the specified Tool Proxy.  As a best practice, the Resource Links should not be explicitly deleted.  Instead, the TC should merely hide or “gray-out” Resource Links that do not have an active Tool Proxy Binding.  If the Tool Proxy is redeployed into the Tool Provider system in the future, and a new Tool Proxy Binding is created, then those old Resource Links will become functional once again.

Use Case Title:

Setting TP Domain Credentials (Basic LTI)

Use Case Local ID:

LTIv1-14

Brief Description:

 The TC administrator configures TP domain credentials for a particular TP.  These credentials apply to new Basic LTI links authored directly in the TC system and also to Basic LTI links imported from a Common Cartridge (see Use Case LTIv1-16).

Level:

Summary

Actors:

·         TC Administrator

·         TP Administrator

Basic Flow of Events:

1.       Generate credentials. The TP Administrator creates the key and secret combination for the TC (where the TC administrator may request a particular key, often the TC domain name).

2.       Exchange the credentials. The TC Administrator obtains the key, secret and TP domain name from the TP administrator.  The LTI standard does not prescribe any particular method for this exchange.

3.       Persist the credentials in the TC. The TC Administrator associates the credentials with TP’s domain and persists this information using a TC-provided dialog or configuration mechanism.

Use Case Title:

Setting Link Level Credentials (Basic LTI)

Use Case Local ID:

LTIv1-15

Brief Description:

  An instructor authors a Basic LTI link and sets the key/password for that link.

Level:

Summary

Actors:

·         Instructor

·         Tool Provider (TP)

Preconditions:

None

Basic Flow of Events:

1.       Exchange Link Level Credentials. The Instructor contacts the TP to obtain access to a provider tool or content.  The TP provides the Instructor with (1) a Basic LTI launch URL or XML snippet for the content or tool, (2) a key that will be used to access this content/tool, and (3) a secret associated with the key.  The LTI standard does not prescribe any mechanism for this exchange. 

2.       Persist Link Level Credentials in the TC system. The Instructor enters the three values (URL or XML snippet, Key, Secret) into a Basic LTI authoring dialog in the TC system.

Use Case Title:

Managing Credentials for Basic LTI Links Imported from a Cartridge

Use Case Local ID:

LTIv1-16

Brief Description:

An Instructor imports a Common Cartridge containing Basic LTI link descriptors into their context and users use the content.

Level:

Summary

Actors:

·         Instructor

·         TC User (typically a Student or Instructor)

Preconditions:

·         A cartridge creator has authored a Common Cartridge that contains one or more Basic LTI Link descriptors.  These descriptors specify the launch URL(s) and other data associated with the links, but they do not contain keys or secrets.

·         In accordance with Use Case LTIv1-14, the TC Administrator has set the domain credentials to particular TP(s) that are referenced in the cartridge.

Basic Flow of Events:

1.       Import the cartridge. The Instructor obtains the Common Cartridge and imports it into a learning context within the TC system.

2.       Use domain credentials during Tool Launch. When a TC User launches a Basic LTI link imported from the Common Cartridge, the TC signs the launch request using the pre-configured credentials associated with the TP address.  In particular, as long as the TC-wide credentials are already installed, the Instructor does not need to take any further action to secure the launch request beyond importing a cartridge.

Alternative Flows:

A.      Domain Credentials are not predefined

If the domain credentials are not predefined within the TC system (i.e. the preconditions to this use case are not satisfied) then at Step 2 the launch requests will not be signed.  In this case, the TC may (at its discretion) refuse to allow the Tool Launch to proceed.  If an unsigned tool launch does occur, the TP may (at its discretion) refuse to honor the request.  To correct such launch failures, it is possible to add domain or link level credentials (in accordance with Use Cases LTIv1-14 and LTIv1-15 respectively) after the cartridge has been imported.

Descriptor

Definition

Class Name

ToolProxyRegistrationRequest

Class Type

container

Parents

n/a

Children

[reg_password]

Description

The ToolProxyRegistrationRequest is a message sent from the Tool Consumer to the Tool Provider to launch the Registration UI as described in the basic Tool Proxy Deployment use case [LTIv1-01]. The Tool Consumer binds this message to an HTML form that is auto-submitted to the Tool Provider.  For an explanation of this process, see the LTI Messaging Framework specification [LTI, 12 MSF].

The vendor_code, tool_code, and tool_version attributes uniquely identify the particular Tool Proxy that is being requested for deployment.  When deployment is initiated as a consequence of  importing an archive (see use case [LTIv1-03]), these attributes are obtained directly from the Tool Proxy Locator.  When deployment is initiated via the Tool Proxy Request Form (see use case [LTIv1-02]), the values for these attributes will not be defined.  In this case, the administrator will typically need to choose the target Tool Proxy during his or her interactions with the Deployment UI.   Alternatively, the Tool Provider might be able to infer the Tool Proxy from the URL to which the ToolProxyRegistrationRequest was submitted.  In other words, the Tool Provider might define a different Deployment URL for each Tool Proxy. 

Descriptor

Definition

Attribute Name

reg_password

Data Type

String

Value Space

n/a

Multiplicity

1

Description

This is the tool registration password. A single-use registration password is used when the TP submits the Tool Proxy to the TC.  This password should be valid for a few hours, which is enough to cover an extended interaction between the TC administrator and the TP deployment application.

Descriptor

Definition

Class Name

RegistrationMixin

Class Type

container

Parents

n/a

Children

[tool_version, tool_code, vendor_code, tc_profile_url], ordered

Description

This mixin encapsulates parameters that the Tool Provider requires in order to register (or reregister) a Tool Proxy with a given Tool Consumer.

Descriptor

Definition

Attribute Name

tool_version

Data Type

NormalizedString

Value Space

n/a

Multiplicity

0..1

Description

This parameter specifies which version of the Tool Proxy is being requested for deployment.  The value corresponds to the tool_info/version value in the Tool Profile.

Descriptor

Definition

Attribute Name

tool_code

Data Type

Name

Value Space

n/a

Multiplicity

0..1

Description

This parameter identifies the Tool Proxy that is being requested for deployment.  The value corresponds to the tool_info/code value in the Tool Profile.

Descriptor

Definition

Attribute Name

vendor_code

Data Type

Name

Value Space

n/a

Multiplicity

0..1

Description

This parameter indicates the 'expected' vendor for this registration request. 

Descriptor

Definition

Attribute Name

tc_profile_url

Data Type

URL

Value Space

n/a

Multiplicity

1

Description

This is a fully qualified URL pointing to the Tool Consumer Profile.  The Tool Provider should append the lti version as a parameter to this url: lti_version=<ltiversion>.

If the lti_version is not specified or if the specified version is not explicitly supported by the Tool Consumer then the Tool Consumer should return a profile for the newest version of LTI that they support.

Descriptor

Definition

Class Name

ToolProxyReregistrationRequest

Class Type

container

Parents

n/a

Children

n/a

Description

This message initiates a re-registration activity.  The Tool Provider responds to this request by invoking the reregisterTool operation on the ToolProxyRegistration service.

Literal Value

Description

success

Indicates that the Tool Proxy registration process completed successfully.

Descriptor

Definition

Class Name

CoreMessageMixin

Class Type

container

Parents

n/a

Children

[lti_version, message_type, custom], ordered

Description

This mixin is a container that specifies the LTI version and declares the message type.  It also holds an optional collection of custom properties.

All LTI messages must inherit this mixin.

Descriptor

Definition

Attribute Name

lti_version

Data Type

NormalizedString

Value Space

For the current version of the LTI Specification (which you are now reading), this attribute must have the value "LTI-1p0".

Multiplicity

1

Description

This attribute specifies the version of the LTI standard to which the message conforms.

Descriptor

Definition

Attribute Name

message_type

Data Type

NormalizedString

Value Space

n/a

Multiplicity

1

Description

This is an identifier for the type of message.  Each concrete message that includes the CoreMessageMixin defines a distinct value for this parameter.

Descriptor

Definition

Attribute Name

custom

Data Type

PropertySet

Value Space

n/a

Multiplicity

0..1

Description

This list contains custom parameters declared in the Tool Profile.

Descriptor

Definition

Class Name

LTIToolProxyMixin

Class Type

container

Parents

n/a

Children

[tool_proxy_guid]

Description

All LTI messages originating from a registered Tool Proxy of the Tool Consumer include this mixin.  The mixin contains the GUID for the Tool Proxy.

Descriptor

Definition

Attribute Name

tool_proxy_guid

Data Type

GUID

Value Space

n/a

Multiplicity

1

Description

This is the GUID string that is returned from the registerTool method in the Tool Registration Service.

Descriptor

Definition

Class Name

LaunchMixin

Class Type

container

Parents

n/a

Children

[user_id, roles, launch_presentation], ordered

Description

This is a common mixin used by all authenticated launch requests.

Descriptor

Definition

Attribute Name

user_id

Data Type

Name

Value Space

n/a

Multiplicity

1

Description

This is an identifier for the user that is locally unique within the Tool Consumer. 

This identifier should not carry any personally identifiable information.

A globally unique identifier for the user may be formed by combining the Tool Consumer Instance GUID with the user_id into a sourcedid of the form "<ToolConsumerInstanceGUID>:<user_id>". 

Descriptor

Definition

Attribute Name

roles

Data Type

String

Value Space

n/a

Multiplicity

1..*

Description

This is a comma-separated list of URN values for the roles of the user.  The vocabulary for role names is open, but the list must include at least one role from the LIS vocabulary.  In the case of LIS context roles, it is permissible to identify the role by its 'handle' only - rather than a fully qualified URN value as required for other vocabularies.  Thus, LIS context roles form the default vocabulary for LTI roles.

Descriptor

Definition

Attribute Name

launch_presentation

Data Type

LaunchPresentation

Value Space

n/a

Multiplicity

0..1

Description

presentation is optional and aims at giving hints to the Tool Producer on how to display its content.

Descriptor

Definition

Class Name

ContextMixin

Class Type

container

Parents

n/a

Children

[context]

Description

This is the mixin for all launch requests that are made from a specific context (such as a course section) in the Tool Consumer.

Descriptor

Definition

Attribute Name

context

Data Type

Context

Value Space

n/a

Multiplicity

1

Description

This is a container that holds information about the context from which the message originates.

Descriptor

Definition

Class Name

LaunchPresentation

Class Type

container

Parents

LaunchMixin

Children

[locale, css_url, document_target, window_name, width, height, return_url], ordered

Description

Container for all the parameters that are used by the Tool Provider to manage the User Interface

Descriptor

Definition

Attribute Name

locale

Data Type

String

Value Space

n/a

Multiplicity

1

Description

language, country and variant separated by underscores. Language is the lower-case, two-letter code as defined by ISO-639 (list of codes available at http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt). Country is the upper-case, two-letter code as defined by ISO-3166 (list of codes available at http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html). Country and variant codes are optional.

Descriptor

Definition

Attribute Name

css_url

Data Type

URL

Value Space

n/a

Multiplicity

0..1

Description

This is the URL for a cascading style sheet that the TP can use to render web pages in a style that matches the look of the TC.

Descriptor

Definition

Attribute Name

document_target

Data Type

DocumentTarget

Value Space

Enumerated as: {frame, iframe, window}.

 For descriptions of these values, see Table 5.50

Multiplicity

0..1

Description

The value should be either ‘frame’, ‘iframe’ or ‘window’.  This value is purely informative; it informs the TP how the destination within the tool is going to be rendered in the TC. 

When the value is "window", the tool will be rendered in a new window. In this case, the name for the new window may be specified by the "window_name" attribute.

When the value is "frame", the tool will be rendered in the same frame (or current window) where the link appears.

When the value is "iframe", the TC will open a new iframe in which to place the tool.

Descriptor

Definition

Attribute Name

window_name

Data Type

NormalizedString

Value Space

n/a

Multiplicity

0..1

Description

Descriptor

Definition

Attribute Name

width

Data Type

String

Value Space

n/a

Multiplicity

0..1

Description

the width of the window or frame where the content from the Tool will be displayed

Descriptor

Definition

Attribute Name

height

Data Type

String

Value Space

n/a

Multiplicity

0..1

Description

the height of the window or frame where the content from the Tool will be displayed

Descriptor

Definition

Attribute Name

return_url

Data Type

URL

Value Space

n/a

Multiplicity

0..1

Description

URL where the Tool Provider can redirect the user back to the Tool Consumer interface. This URL may accept some additional parameters for specific LTIMessage types. See the documentation of each message type for details.

Literal Value

Description

frame

The Tool opens in the same frame that contained the link.

iframe

The Tool opens within an iframe nested inside the frame that contains the link.

window

The Tool opens in a new window.

Craig Dunk

Desire2learn

Colin Smythe

IMS Global

Greg McFall

Pearson

Matt Stoelting

Cengage

Mark McKell

IMS Global

John Tibbetts

VitalSource

Lance Neumann

Blackboard

Stephen Vickers

IMS Global

Charles Severance

University of Michigan

Version No.

Release Date

Comments

Public Draft v2.0

1 November 2012

First release of the Tool Management specification for LTI 2.