The LTI 1.1.1 specification includes 2 sets of elements that are used by a tool provider to figure out the context of a launch:

• tool_consumer_instance (_guid, _name, _description, _url and _contact_email…that last if you are really desparate)
• context (_id, _type, _title, and _label)

We can think of the context_id as as the class id. But the specification describes tool_consumer_instance_guid like this:

This is a unique identifier for the TC [tool consumer].  A common practice is to use the DNS [i.e. a domain name rather than a traditional GUID] of the organization or the DNS of the TC instance.  If the organization has multiple TC instances, then the best practice is to prefix the domain name with a locally unique identifier for the TC instance.  In the single-tenancy case, the tool consumer data can be often be derived from the oauth_consumer_key.  In a multi-tenancy case this can be used to differentiate between the multiple tenants within a single installation of a Tool Consumer. This parameter is strongly recommended in systems capable of multi-tenancy.

Unfortunately, the ambiguity of what the tool_consumer_instance represents causes a real problem for providers in K-12 education. The tools and content that they provide are often differentiated for the specific state, district, and school where they are being consumed. For example, they might show different state standard correlations to teachers in Alabama than they would to teachers in Oregon. And providers that control access to their tools or content need to figure out if the launch is authorized. In K-12 education, the customer can be the state DOE, a district (or group of districts), a school, or even the classroom teacher.

To solve both of those problems for the provider, K-12 tool consumers should send enough information for the provider to figure out if they can grant access to the learning object and which version to present. The Consumer web site does this by sending the state, LEA (general form of a U.S. school district) and school with each launch. To ensure that providers know which state, LEA and school the Consumer web site is talking about, it uses data from the Elementary/Secondary Information System (ElSi) of the National Center for Education Statistics (NCES).

The LTI specification says that if a tool consumer “wants to extend [the Basic Launch Data], they should prefix all fields not described herein with ‘ext_'”. Therefore, the Consumer web site introduces 6 optional context parameters:

• ext_context_state_id
  The state abbreviation which is a key value in the data that ElSi provides. For example, “OR”.
• ext_context_state_name
  The name of the state. For example, “Oregon”.
• ext_context_lea_sourcedid
  The NCES id and/or the State DOE id for the LEA. If both are included, they are separated by a comma. For example, “nces.ed.gov:4101920,ext_context_state:00000000002243”.
• ext_context_lea_name
  The name of the LEA. For example, “BEAVERTON SD 48J”.
• ext_context_school_sourcedid
  The NCES id and/or the LEA id for the school. If both are included, they are separated by a comma. For example, “nces.ed.gov:410192000554,ext_context_lea:00000000000000001320”.
• ext_context_school_name
  The name of the school. For example, “WESTVIEW HIGH SCHOOL”.

Given this additional context information, providers can authorize access to their tools and content; and appropriately differentiate the student and teacher experience.

As always the source code is checked in to CodePlex. In particular, see the AddExtendedParameters in AssignmentController and Readme.txt in the App_Data folder.