Learning Tools Interoperability (LTI) Dynamic Registration Specification v1.0

Learning Tools Interoperability (LTI) Dynamic Registration Specification

1EdTech Candidate Final
Version 1.0
1EdTech Candidate Final
Date Issued: 13 October 2020
Status: This document is for review and adoption by the 1EdTech membership.
This version: https://www.imsglobal.org/spec/lti-dr/v1p0/
Latest version: https://www.imsglobal.org/spec/lti-dr/latest/
Errata: https://www.imsglobal.org/spec/lti-dr/v1p0/errata/

IPR and Distribution Notice

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

The following participating organizations have made explicit license commitments to this specification:

Org name Date election made Necessary claims Type
D2L Corporation Oct 18, 2021 No RF RAND (Required Elements)
42 Lines Oct 18, 2021 No RF RAND (Required Elements)

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/speclicense.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/1EdTech-glc-public-forums-and-resources.

© 2020 1EdTech Consortium, Inc. All Rights Reserved.

Trademark information: http://www.imsglobal.org/copyright.html

Abstract

The Learning Tools Interoperability® (LTI®) Dynamic Registration specification, as described in this document, defines a way to automate the exchange of registration information between LTI Platforms and Tools that use the OpenId Connect and oAuth 2 registration flows. This allows Platform administrators to automate tool registrations and avoid tedious and possibly error prone manual configuration while remaining in control of granting or denying Tools access to the Platform.

Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC2119].

An implementation of this specification that fails to implement a MUST/REQUIRED/SHALL requirement or fails to abide by a MUST NOT/SHALL NOT prohibition is considered nonconformant. SHOULD/SHOULD NOT/RECOMMENDED statements constitute a best practice. Ignoring a best practice does not violate conformance but a decision to disregard such guidance should be carefully considered. MAY/OPTIONAL statements indicate that implementers are entirely free to choose whether or not to implement the option.

The Conformance and Certification Guide for this specification may introduce greater normative constraints than those defined here for specific service or implementation categories.

1. Introduction

LTI 1.3 Core [LTI-13] is built on top of OpenId Connect and OAuth 2; alongside its companion specifications, it standardizes the integration of learning tools within learning platforms, allowing users to navigate back and forth between the 2 systems and engage in learning resources in an experience that is as seamless as possible. While LTI 1.3 made the connection between the Learning Platform and the Tool more secure, it actually made the registration of a tool more cumbersome as both parties need to be involved in the exchange of configuration data. This specification aims at addressing this concern by providing an automated way to exchange registration information.

This specification leverages the OpenID Connect Discovery [OIDC-CD], OpenID Connect Dynamic Client Registration [OIDC-Reg], and OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] specifications that are profiled and enriched to reflect the way LTI leverages the OpenId connect and OAuth 2.0 specifications. This specification also adds an additional leg in the protocol to initiate the registration process from the Learning Platform, in the same spirit the Initiate Login URI is used to trigger the OpenId flow in the LTI Core specification.

Key characteristics of LTI registrations are that differ from some typical usage of OpenId Dynamic Registration are:

  • Registration is typically triggered from the learning platform.
  • They are long lived relationship between a tool and a platform.
  • They are usually vetted by platform's stakeholders before to being made available.

As such the registration process is traditionally not meant to be an open dynamic tool registration where a tool can push its configuration to a platform at any time without the platform's intervention; rather, the LTI registration is usually meant to allow platform administrators to automate tool registrations, removing tedious and error prone manual configuration, while still being the actor ultimately granting or denying the tool access to the platform.

2. Platform and Tool Configuration Metadata Definitions

2.1 Platform Configuration

This specification applies the following constraints to the OpenID Discovery openid-configuration metadata definition; the following properties are required unless mentioned otherwise:

Property Usage for LTI Recommendation
issuer Platform's issuer value. As per 1EdTech Security Framework and LTI Specification, the Issuer Identifier is a case-sensitive URL, using the HTTPS scheme, that contains scheme, host, and optionally, port number, and path components, and no query or fragment components.
authorization_endpoint URL of the OAuth 2.0 Authorization Endpoint.
registration_endpoint URL of the registration endpoint; may be a one time use only end-point and/or protected by access token.
jwks_uri URL of the Platform JWK Set endpoint; may be specific per registration if the platform's issued a dedicated discovery end-point for that registration.
token_endpoint URL of the endpoint for the tool to request a token to access LTI (and possibly other) services.
token_endpoint_auth_methods_supported Must contain private_key_jwt; may offer additional values.
token_endpoint_auth_signing_alg_values_supported Must contain RS256; may offer additional values.
scopes_supported Must contain openid and the scopes of the supported LTI services; for example https://purl.imsglobal.org/spec/lti-ags/scope/score. It may contain other non LTI related scopes.
response_types_supported Must contain id_token; may offer additional values.
id_token_signing_alg_values_supported Must contain RS256; may offer additional values. LTI requires the use of asymmetric cryptographic signing algorithms.
claims_supported opendid claims supported by this platform. LTI related claims should not be included unless specified otherwise as those are inferred by the message types.
authorization_server (optional) The authorization server identifier to be used as the aud when requesting an access token. If not specified, the tool must use the token_endpoint as the aud value when requesting an access token.
https://purl.imsglobal.org/spec/lti-platform-configuration A JSON Object object containing LTI specific configuration details for this registration. See below.

The lti-platform-configuration exposes the current LTI capabilities of the platform and may be used by the Tool to tailor its registration process. Its properties are:

Property Definition
product_family_code Product identifier for the platform.
version Version of the software running the platform.
messages_supported An array of all supported LTI message types. See below for message supported properties.
variables (optional) An array of all variables supported for use as substitution parameters.

The message supported indicates support for a specific message type. Its properties are described below, and are required unless mentioned otherwise.

Property Definition
type The message type.
placements (optional) Array of placements indicating where the platform support this link type to be added when the tool is made available.

The lti-platform-configuration and message supported definitions are open for extensions and future additions; implementers must therefore ignore any unknown properties.

Non normative example:


{
    "issuer": "https://server.example.com",
    "authorization_endpoint":  "https://server.example.com/connect/authorize",
    "token_endpoint": "https://server.example.com/connect/token",
    "token_endpoint_auth_methods_supported": ["private_key_jwt"],
    "token_endpoint_auth_signing_alg_values_supported": ["RS256"],
    "jwks_uri": "https://server.example.com/jwks.json",
    "registration_endpoint": "https://server.example.com/connect/register",
    "scopes_supported": ["openid", "https://purl.imsglobal.org/spec/lti-gs/scope/contextgroup.readonly",
       "https://purl.imsglobal.org/spec/lti-ags/scope/lineitem",
       "https://purl.imsglobal.org/spec/lti-ags/scope/result.readonly",
       "https://purl.imsglobal.org/spec/lti-ags/scope/score",
       "https://purl.imsglobal.org/spec/lti-reg/scope/registration"],
    "response_types_supported": ["id_token"],
    "subject_types_supported": ["public", "pairwise"],
    "id_token_signing_alg_values_supported":
      ["RS256", "ES256"],
    "claims_supported":
      ["sub", "iss", "name", "given_name", "family_name", "nickname", "picture", "email", "locale"],
     "https://purl.imsglobal.org/spec/lti-platform-configuration": {
        "product_family_code": "ExampleLMS",
        "messages_supported": [
            {"type": "LtiResourceLinkRequest"},
            {"type": "LtiDeepLinkingRequest"}],
        "variables": ["CourseSection.timeFrame.end", "CourseSection.timeFrame.begin", "Context.id.history", "ResourceLink.id.history"]
    }
}

2.2 Tool Configuration

This specification applies the following constraints to the format defined by the OIDCReg tool registration metadata; the following properties are required unless mentioned otherwise; a tool may include additional properties.

Property Usage for LTI Recommendation
application_type web
grant_types Must include client_credentials and implicit.
response_types Must include id_token. Other values may be included.
redirect_uris As per OIDCReg specification
initiate_login_uri As per OIDCReg specification. URI used by the platform to initiate the LTI launch.
client_name Name of the Tool to be presented to the End-User. Localized representations may be included as described in Section 2.1 of the [OIDC-Reg] specification.
jwks_uri This specification requires the tool to expose its public key using a JSON Web Key Set URI. The value does not need to be specific for this registration i.e. a tool may use the same JSON Web Key Set URI for multiple registrations.
logo_uri (optional) As per OIDCReg specification.
token_endpoint_auth_method private_key_jwt
contacts (optional) As per OIDCReg specification.
client_uri (optional) As per OIDCReg specification. The platform should present this information to the platform's end users of that tool. Localized representations may be included as described in Section 2.1 of the OIDCReg specification.
tos_uri (optional) As per OIDCReg specification. The platform should present this information to the platform's end users of that tool. Localized representations may be included as described in Section 2.1 of the OIDCReg specification.
policy_uri (optional) As per OIDCReg specification. The platform should present this information to the platform's end users of that tool. Localized representations may be included as described in Section 2.1 of the OIDCReg specification.
https://purl.imsglobal.org/spec/lti-tool-configuration A JSON Object object containing LTI specific configuration details for this registration. See below.
scope As per rfc7591, String containing a space-separated list of scope values the tool requests access to. A tool must require the scopes related to the LTI (and possibly other) services it wishes to be granted access for. A platform should not grant access to services that a tool has not explicitly requested. However a platform administrator may after deployment further restrict access and the tool will need to adapt at runtime if a service access is no more granted.

The lti-tool-configuration defines LTI specific configuration. Its properties are described below. A platform must ignore unknown properties. If proprietary extensions are added, they should be on the URI form, for example: https://myplatform.example.org/branding to avoid any collision with future additions.

Property Definition
domain The primary domain covered by this tool; protocol must not be included. For example mytool.example.org
secondary_domains (optional) Array of domains also covered by this tool
deployment_id (optional) In the case where a platform is combining registration and deployment of a tool, the platform may pass the LTI deployment_id associated with this client registration's deployment.
target_link_uri The default target link uri to use unless defined otherwise in the message or link definition.
custom_parameters (optional) JSON Object where each value is a string. Custom parameters to be included in each launch to this tool. If a custom parameter is also defined at the message level, the message level value takes precedence. The value of the custom parameters may be substitution parameters as described in the LTI Core [LTI-13] specification.
description (optional) A short plain text description of the tool. Localized representations may be included as described in Section 2.1 of the [OIDC-Reg] specification.
messages An array of messages supported by this tool. See below for message properties.
claims An array of claims indicating which information this tool desire to be included in each idtoken. The tool should be explicit about identity claims such as sub, given_name, ... It should omit LTI claims when the inclusion of those is driven by the message definition.

The message indicates support for a specific message type. Its properties are described below, and are required unless mentioned otherwise. A platform must ignore unknown properties.

Property Definition
type The message type
target_link_uri (optional) Target link uri to apply when launching this message. If not present, the tool's target_link_uri defined above apply.
label (optional) A label a platform may apply to decorate that link. Localized representations may be included as described in Section 2.1 of the [OIDC-Reg] specification.
icon_uri (optional) An icon the platform may apply to decorate the link.
custom_parameters (optional) JSON Object where each value is a string. Custom parameters to be included in each launch to this tool using this message. If a custom parameter is also defined at the tool level, the message level value takes precedence. As per LTI Core [LTI-13] Specification, when the value of a substitution parameter starts with a $, it indicates the use of a substitution parameter.
placements (optional) Array of placements indicating where the platform should add links for this message when this tool is made available.

Non normative example:


{
    "application_type": "web",
    "response_types": ["id_token"],
    "grant_types": ["implict", "client_credentials"],
    "initiate_login_uri": "https://client.example.org/lti",
    "redirect_uris":
      ["https://client.example.org/callback",
       "https://client.example.org/callback2"],
    "client_name": "Virtual Garden",
    "client_name#ja": "バーチャルガーデン",
    "jwks_uri": "https://client.example.org/.well-known/jwks.json",
    "logo_uri": "https://client.example.org/logo.png",
    "client_uri": "https://client.example.org",
    "client_uri#ja": "https://client.example.org?lang=ja",
    "policy_uri": "https://client.example.org/privacy",
    "policy_uri#ja": "https://client.example.org/privacy?lang=ja",
    "tos_uri": "https://client.example.org/tos",
    "tos_uri#ja": "https://client.example.org/tos?lang=ja",
    "token_endpoint_auth_method": "private_key_jwt",
       "contacts": ["ve7jtb@example.org", "mary@example.org"],
    "scope": "https://purl.imsglobal.org/spec/lti-ags/scope/score",
    "https://purl.imsglobal.org/spec/lti-tool-configuration": {
        "domain": "client.example.org",
        "description": "Learn Botany by tending to your little (virtual) garden.",
        "description#ja": "小さな(仮想)庭に行くことで植物学を学びましょう。",
        "target_link_uri": "https://client.example.org/lti",
        "custom_parameters": {
            "context_history": "$Context.id.history"
        },
        "claims": ["iss", "sub", "name", "given_name", "family_name"],
        "messages": [
            {
                "type": "LtiDeepLinkingRequest",
                "target_link_uri": "https://client.example.org/lti/dl",
                "label": "Add a virtual garden",
                "label#ja": "バーチャルガーデンを追加する",
                "custom_parameters": {
                    "botanical_set":"12943,49023,50013"
                }
            }
        ]
    }
}

2.3 Tool Configuration from the Platform

When the tool configuration is exposed by the Platform, for example as an acknowledgment of registration, it contains the following additional attributes:

client_id As per [OIDC-Reg] specification., the client_id associated to the tool's registration.
registration_client_uri (optional) As per OIDCReg specification, the registration endpoint the tool may use to get and possibly alter the current registration.

Non normative example:


{
    "client_id": "709sdfnjkds12",
    "registration_client_uri":
      "https://server.example.com/connect/register?client_id=709sdfnjkds12",
    "application_type": "web",
    "response_types": ["id_token"],
    "grant_types": ["implict", "client_credentials"],
    "initiate_login_uri": "https://client.example.org/lti",
    "redirect_uris":
      ["https://client.example.org/callback",
       "https://client.example.org/callback2"],
    "client_name": "Virtual Garden",
    "jwks_uri": "https://client.example.org/.well-known/jwks.json",
    "logo_uri": "https://client.example.org/logo.png",
    "token_endpoint_auth_method": "private_key_jwt",
    "contacts": ["ve7jtb@example.org", "mary@example.org"],
    "scope": "https://purl.imsglobal.org/spec/lti-ags/scope/score",
    "https://purl.imsglobal.org/spec/lti-tool-configuration": {
        "domain": "client.example.org",
        "target_link_uri": "https://client.example.org/lti",
        "custom_parameters": {
            "context_history": "$Context.id.history"
        },
        "claims": ["iss", "sub", "name", "given_name", "family_name"],
        "messages": [
            {
                "type": "LtiDeepLinkingRequest",
                "target_link_uri": "https://client.example.org/lti/dl",
                "label": "Add a virtual garden"
            }
        ]
    }
}

3. LTI Open ID Connect Dynamic Registration Protocol

3.1 Overview

At its core, the protocol of registration is the configuration discovery and dynamic registration covered by the OIDCDiscovery and OIDCReg specifications. However, to accommodate the specific usage of LTI where a tool is usually from the platform rather than the client, and later on made available, a UI flow has been added to trigger that registration process from the platform UI:

The registration is thus done in 4 phases:

  1. The platform initiates the registration by using a tool provided initiate registration endpoint. This is mediated by the browser, typically by opening an IFrame to the initiate registration end-point.
  2. 1 The tool may include a UI to complete the registration on the tool side.
  3. The tool discovers the platform's OpenId configuration using the provided openid-configuration endpoint, as defined in OIDCDiscovery specification.
  4. The tool uses the registration endpoint present in the OpenId configuration to request a registration as per OIDCReg specification. The platform must immediately grant or deny the registration. A successful registration means the tool is properly configured, but it is not activated yet.
  5. The platform administrator may then review, alter, reject or activate the newly added registration.

In the context of this specification, the tool plays the role of the client or relying party, and the learning platform the one of the OpenId provider.

LTI Core Registration flow

3.2 Exchange of Configuration, Not a Contract Negotiation

While the openid-configuration exposes the platform's offered capabilities to the tool, and the tool's registration includes the scopes and claims it requests access for, this specification is not aimed at negotiating a contract. A platform should accept a registration and actually allow only a subset of the required capabilities, reflected in the returned tool's registration. Furthermore, a platform admin may always either restrict or extend the offered capabilities (claims, scopes, variables) to a given tool. As usual, an LTI Tool should not make assumptions about what is available and handle gracefully the cases were some capabilities such as claims and/or services are not exposed.

3.3 Step 1: Registration Initiation Request

The registration initiation launch allows the registration flow to be triggered from the platform UI, typically by opening an IFrame or a new Tab to that endpoint. How the initiate registration request endpoint is shared is not specified and happens out of band. It may be the same registration endpoint for all registration request or specific for a given registration request; for example the tool may generate a specific registration URL for each institution and communicate it to the platform administrator to trigger the registration.

The initiation launch is a User Agent redirect to the initiation registration URL and appends the following query parameters to the URL:

  • openid_configuration: the endpoint to the open id configuration to be used for this registration, encoded as per [RFC3986] Section 3.4.
  • registration_token (optional): the registration access token. If present, it must be used as the access token by the tool when making the registration request to the registration endpoint exposed in the openid configuration.

The registration token should be:

  • short lived - typically 1 hour to allow enough time for some UI interaction on the tool side happening before the actual registration request is made.
  • usable only once - the token must not allow more than one registration

3.4 Step 2: Discovery and openid Configuration

This section follows the OIDCDiscovery specification but relaxes the requirement on the OpenId Configuration Endpoint's URL since the URL is actually passed during the initiate registration request, allowing the platform to possibly tailor a configuration for a given registration.

The Platform must make to the OpenId Configuration URL's endpoint as a path concatenated with the Issuer. If applicable, the appended path should be the OIDCDiscovery defined /.well-known/openid-configuration. The URL may also contain query parameters. The URL must not contain any fragment parameter.

For example, considering the OpenId Configuration declares the issuer as https://platform.example.com, the following URLs would be valid OpenId Configuration endpoints:

The following URLs are not valid and a Tool must abort the registration:

The tool receives the openid configuration endpoint as a query parameter in the initiate registration request. The tool must not make any assumption about the openid configuration endpoint time-to-live, nor should it assume that the endpoint is meant to be shared and/or reused for other registration requests.

For example, a platform may issue a short lived endpoint to a specific tool administrator so that she can initiate a registration; the registration endpoint present in the openid configuration would then be a single usage endpoint, only allowing a single tool to be registered. Registering another tool would require the platform to deliver another openid-configuration endpoint to the tool's administrator.

3.5 Step 3: Client Registration

This section follows the [OIDC-Reg] specification. The tool requests a registration using the registration_endpoint advertised in the openid-configuration. As per OIDCReg section 3, this end point should preferably be open but may be short lived; a platform may require the tool to include an initial access token in the request. If so, the registration initiation request will include the token to use for that registration request.

3.5.1 Issuer and OpenID Configuration URL Match

Before to actually register, to guard against impersonation attacks, a tool must validate the OpenId Configuration URL using the rules described in the previous section and reject the registration request if the validation fails.

A Tool may apply some additional validation based on the product_family_code and version.

3.5.2 Client Registration Request

As defined in [OIDC-Reg] specification Client Registration Request, the tool sends an HTTP POST message to the Client Registration Endpoint with the desired tool configuration. The content type must be application/json. If provided by the platform, the tool must include the token as Bearer Token in the Authentication http header.

Non normative example:


POST /connect/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ .

{
    "application_type": "web",
    "response_types": ["id_token"],
    "grant_types": ["implict", "client_credentials"],
    "initiate_login_uri": "https://client.example.org/lti",
    "redirect_uris":
      ["https://client.example.org/callback",
       "https://client.example.org/callback2"],
    "client_name": "Virtual Garden",
    "client_name#ja": "バーチャルガーデン",
    "jwks_uri": "https://client.example.org/.well-known/jwks.json",
    "logo_uri": "https://client.example.org/logo.png",
    "policy_uri": "https://client.example.org/privacy",
    "policy_uri#ja": "https://client.example.org/privacy?lang=ja",
    "tos_uri": "https://client.example.org/tos",
    "tos_uri#ja": "https://client.example.org/tos?lang=ja",
    "token_endpoint_auth_method": "private_key_jwt",
    "contacts": ["ve7jtb@example.org", "mary@example.org"],
    "scope": "https://purl.imsglobal.org/spec/lti-ags/scope/score https://purl.imsglobal.org/spec/lti-nrps/scope/contextmembership.readonly",
    "https://purl.imsglobal.org/spec/lti-tool-configuration": {
        "domain": "client.example.org",
        "description": "Learn Botany by tending to your little (virtual) garden.",
        "description#ja": "小さな(仮想)庭に行くことで植物学を学びましょう。",
        "target_link_uri": "https://client.example.org/lti",
        "custom_parameters": {
            "context_history": "$Context.id.history"
        },
        "claims": ["iss", "sub", "name", "given_name", "family_name"],
        "messages": [
            {
                "type": "LtiDeepLinkingRequest",
                "target_link_uri": "https://client.example.org/lti/dl",
                "label": "Add a virtual garden",
                "label#ja": "バーチャルガーデンを追加する",
            }
        ]
    }
}

3.6 Client Registration Response

3.6.1 Successful Registration

As per [OIDC-Reg] upon successful registration a application/json the platform must return a response containing the newly created client_id. It then echoes the client configuration as recorded in the platform, which may differ from the configuration passed in the request based on the actual platform's capabilities and restrictions.

The registration response may include a Client Configuration Endpoint and a Registration Access Token to allow a tool to read or update its configuration.

In the case where a Platform is combining the client registration with the tool's actual deployment, it may also include the deployment_id in the LTI Tool Configuration section.

Non normative example:


{
    "client_id": "709sdfnjkds12",
    "registration_client_uri":
      "https://server.example.com/connect/register?client_id=709sdfnjkds12",
    "application_type": "web",
    "response_types": ["id_token"],
    "grant_types": ["implict", "client_credentials"],
    "initiate_login_uri": "https://client.example.org/lti",
    "redirect_uris":
      ["https://client.example.org/callback",
       "https://client.example.org/callback2"],
    "client_name": "Virtual Garden",
    "jwks_uri": "https://client.example.org/.well-known/jwks.json",
    "logo_uri": "https://client.example.org/logo.png",
    "token_endpoint_auth_method": "private_key_jwt",
    "contacts": ["ve7jtb@example.org", "mary@example.org"],
    "scope": "https://purl.imsglobal.org/spec/lti-ags/scope/score",
    "https://purl.imsglobal.org/spec/lti-tool-configuration": {
        "domain": "client.example.org",
        "target_link_uri": "https://client.example.org/lti",
        "custom_parameters": {
            "context_history": "$Context.id.history"
        },
        "claims": ["iss", "sub"],
        "messages": [
            {
                "type": "LtiDeepLinkingRequest",
                "target_link_uri": "https://client.example.org/lti/dl",
                "label": "Add a virtual garden"
            }
        ]
    }
}

3.6.2 Client Registration Error Response

As per OIDCReg, any configuration that cannot be registered should be rejected with a 400 Bad Request response with a JSON Object describing the error in the body.

3.7 Step 4: Registration Completed and Activation

Once the registration is completed, successfully or not, the tool should notify the platform by sending an HTML5 Web Message [webmessaging] indicating the window may be closed. Depending on whether the platform opened the registration in an IFrame or a new tab, either window.parent or window.opener should be called.

The LTI Message must be a Javascript object having a property subject with the value org.imsglobal.lti.close.

The platform may use this signal to trigger a UI refresh and display a post registration screen.

Non normative example:


(window.opener || window.parent).postMessage({subject:'org.imsglobal.lti.close'})

The platform should then present to the platform administrator a way to access the newly added tool for reviewing, and possibly applying modification and eventually activating the tool, making it available to be used by the platform users.

4. Client Registration Endpoint

Updating a registration through an API call raises security and privacy concerns. If a platform decides to expose a registration endpoint for update, it should not immediately apply any change pushed by the client. Those changes, like in the initial registration, would need to be vetted by a Platform Administrator before being applied.

This specification in this iteration does not propose any particular mechanism under which a change would be made provisional and later on confirmed or denied, nor how a tool would know if those changes were applied outside of having those reflected in the actual LTI message payloads and/or in the authorized service accesses. A tool must then assume even after successful registration update the updated registration will not apply right away.

This specification does propose to protect the registration endpoint using the same mechanism as the other LTI Services, that is through the use of a properly scoped access token acquired using the Client Credentials grant flow.

4.1 Registration Update

As per OIDCReg, the Client Registration Endpoint should allow a Tool to retrieve its current configuration in the same format as the registration response by making a GET request to the endpoint, using the provided registration access token. Alternatively, the platform may allow the tool to retrieve a registration token using the token endpoint (see scopes below).

In addition, a platform may allow a tool to use the registration endpoint to update its configuration by issuing a PUT request with a client configuration payload as described in the Client Registration Request. A platform must never change a registration client_id when updating a registration.

A platform should then return the client registration reflecting the pending configuration update.

4.2 Scopes

Since LTI is based on client credentials grant, this specification adds an additional scopes allowing the tool to retrieve an access token rather than relying on a fixed dedicated token.

The scopes are:

A platform supporting a tool to access the registration endpoint should advertise those scopes in the list of supported scopes in the openid configuration response.

A. References

A.1 Normative references

[LTI-13]
1EdTech Learning Tools Interoperability® Core Specification v1.3. C. Vervoort; N. Mills. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/
[OIDC-CD]
OpenID Connect Discovery 1.0. Edmund Jay; John Bradley; Michael B. Jones. The OpenID Foundation. URL: https://openid.net/specs/openid-connect-discovery-1_0.html
[OIDC-Reg]
OpenID Connect Dynamic Client Registration 1.0. Nat Sakimura; John Bradley; Michael B. Jones. The OpenID Foundation. URL: https://openid.net/specs/openid-connect-registration-1_0.html
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC7591]
OAuth 2.0 Dynamic Client Registration Protocol. J. Richer, Ed.; M. Jones; J. Bradley; M. Machulak; P. Hunt. IETF. July 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7591
[webmessaging]
HTML5 Web Messaging. Ian Hickson. W3C. 19 May 2015. W3C Recommendation. URL: https://www.w3.org/TR/webmessaging/

B. List of Contributors

The following individuals contributed to the development of this document:

Name Organization Role
Andy Fisher42 Lines, Inc.
Peter FranzaPennsylvania State University
Viktor HaagD2L
Martin LenordTurnitin
Karl LloydInstructure
Mark McKell1EdTech
Bracken Mosbacker1EdTech
Eric PrestonBlackboard
Maggie SazioD2L
Charles SeveranceUniversity of Michigan
James TseGoogle
Claude VervoortCengageEditor

1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this document ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

1EdTech would appreciate receiving your comments and suggestions.

Please contact 1EdTech through our website at http://www.imsglobal.org.

Please refer to Document Name: Learning Tools Interoperability (LTI) Dynamic Registration Specification 1.0

Date: 13 October 2020

Specification Images: