Provide Dynamic Registration

1 Initial Problem

ILIAS currently supports both LTI 1.1 and LTI 1.3, acting both as an LTI consumer (platform) and as an LTI provider (tool). From a configuration and usability perspective, these two versions differ significantly. LTI 1.1 relies on a comparatively simple authentication mechanism based on OAuth 1.0, which typically requires only a small number of parameters, such as a consumer key and a shared secret. As a result, configuring an LTI 1.1 integration is usually straightforward and can be completed with minimal technical expertise.

In contrast, LTI 1.3 introduces a much more complex configuration process. This increased complexity is primarily due to its reliance on modern web security standards, including OAuth 2.0, OpenID Connect, and JSON Web Tokens (JWT). These technologies are widely adopted in contemporary secure web applications and offer substantial improvements in terms of security, scalability, and interoperability. For example, they eliminate the use of shared secrets, enable fine-grained access control, and support secure key rotation through public-key cryptography.

However, these advantages come at the cost of a more demanding setup process. LTI 1.3 requires the explicit definition and exchange of numerous configuration parameters between the consumer (such as ILIAS) and the external tool provider. These parameters include, among others, identifiers for both platforms, cryptographic key endpoints, authorization and token endpoints, redirect URIs, and deployment-specific identifiers. Each of these values must be correctly generated, communicated, and configured on both sides of the integration.

Because this exchange is often performed manually, the configuration process becomes lengthy and error-prone. Administrators must carefully follow a sequence of steps across two independent systems, frequently copying and pasting values between configuration interfaces. Even minor mistakes, such as incorrect URLs, mismatched identifiers, or missing parameters, can cause authentication failures that are difficult to diagnose. Consequently, while LTI 1.3 significantly enhances security compared to LTI 1.1, its manual configuration process represents a substantial usability challenge, particularly for users without in-depth knowledge of modern authentication protocols.

Typical parameters that must be collected and entered manually include:

This process:

As a result, users frequently make mistakes during setup, leading to failed launches, invalid tokens, or misconfigured trust relationships. This steep learning curve significantly reduces usability and adoption of LTI 1.3, despite its technical advantages.

2 Conceptual Summary

The main challenge of configuring LTI 1.3 integrations lies in the manual exchange of a large number of security- and deployment-related parameters between the LTI consumer (platform) and the LTI provider (tool). Dynamic Registration (DR) was introduced in the LTI 1.3 specification precisely to mitigate this issue by automating the establishment of trust between both parties.

Instead of requiring users to manually exchange and configure all security parameters, Dynamic Registration allows the consumer and provider to automatically establish trust through a standardized registration flow.

2.1 Automating the Exchange of Configuration Data

Dynamic Registration replaces the traditional manual configuration process with a standardized, machine-readable registration workflow. Instead of requiring administrators to gather and copy configuration values from one system to another, DR allows the consumer to retrieve the provider’s configuration automatically using a dedicated registration endpoint.

In practice, the user only needs to provide a single registration URL from the provider to the consumer. From this URL, the consumer can discover all relevant metadata, including:

This automatic discovery significantly reduces the amount of information that must be handled manually by the user.

2.2 Reduction of Manual Steps and Human Error

Without Dynamic Registration, administrators must carefully follow a long, ordered list of configuration steps on both platforms. Each step introduces the risk of human error, such as copying incorrect values, misconfiguring endpoints, or using inconsistent identifiers. DR removes most of these risks by shifting the responsibility for configuration consistency from the user to the software itself.

By exchanging configuration data directly between systems in a standardized format, Dynamic Registration ensures that:

As a result, configuration errors that previously led to failed launches or authentication issues are largely avoided.

2.3 Improved Usability for Non-Expert Users

One of the major benefits of Dynamic Registration is that it lowers the technical barrier for using LTI 1.3. Administrators no longer need in-depth knowledge of OAuth 2.0, OpenID Connect, or JWT to successfully configure an integration. Instead, the registration process becomes more similar in complexity to LTI 1.1, while still preserving the enhanced security properties of LTI 1.3.

This improvement in usability is particularly important for platforms like ILIAS, which are often administered by educators or institutional staff rather than security experts.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

LTI consumer form

In the current LTI implementation, ILIAS already provides a configuration form for the LTI consumer that includes a field for entering a Dynamic Registration URL. From a user interface perspective, this suggests that Dynamic Registration is conceptually supported and intended to simplify the configuration of LTI 1.3 tools.

The purpose of this form field is to allow administrators to initiate the Dynamic Registration workflow by supplying the registration endpoint exposed by the LTI tool provider. Ideally, once this URL is entered and submitted, ILIAS should automatically perform the Dynamic Registration process: retrieve the tool’s metadata, register itself as a client, and store all required configuration parameters internally.

However, in the current state of the implementation, this Dynamic Registration functionality is not operational. Although the user interface allows the Dynamic Registration URL to be entered, the underlying logic required to complete the registration flow is either incomplete or missing. As a result, the form does not trigger the full OpenID Connect–based registration process defined by the LTI 1.3 specification.

Because Dynamic Registration is not actually executed, administrators are still required to manually configure the LTI 1.3 integration. This includes entering multiple technical parameters, such as issuer identifiers, endpoints, keys, and deployment information, despite the presence of a form element that suggests automation. This mismatch between the user interface and the system behavior can lead to confusion, as users may expect the configuration to be handled automatically once the registration URL is provided.

LTI provider form

While the LTI consumer form already contains a field for the Dynamic Registration URL, Dynamic Registration inherently involves both roles: the consumer (platform) and the provider (tool). In its role as an LTI provider, ILIAS must expose a well-defined registration endpoint that external platforms can use to initiate Dynamic Registration.

At present, the LTI provider configuration in ILIAS does not explicitly expose or manage a Dynamic Registration URL. This makes it difficult or impossible for external LTI platforms to dynamically register ILIAS as a tool, even though the underlying protocol allows and expects such a mechanism.

The proposed solution is to extend the LTI provider configuration form with a dedicated field that clearly exposes the Dynamic Registration URL of ILIAS when acting as an LTI provider. 

This URL will:

• Represent the entry point for external platforms to initiate Dynamic Registration
  
• Point to an endpoint that serves ILIAS’ OpenID Connect and LTI metadata
• Be easily discoverable and copyable by administrators

3.3 New User Interface Concepts

The Form in Administration is only based on KS-Elements.

3.4 Accessibility Implications

The Form in Administration is only based on KS-Elements, therefore there are no Accessibilty Implications.

4 Technical Information

Dynamic Registration in LTI 1.3 is defined as an extension of OpenID Connect Dynamic Client Registration, adapted to the requirements of the LTI ecosystem. Its goal is to allow an LTI platform (consumer) and an LTI tool (provider) to automatically establish a trusted relationship without manual exchange of configuration parameters.

4.1 Prerequisites and Roles

Dynamic Registration involves two main components:

Both components must support:

4.2 Discovery Phase

4.2.1 Registration Initiation URL

The process begins when the user provides the Dynamic Registration initiation URL of the tool to the platform. This URL is typically exposed by the tool provider and points to a registration endpoint. This is usually the only value the user must manually enter.

4.2.2 Retrieval of Tool Metadata

The platform sends an HTTPS request to the registration endpoint. In response, the tool provides a JSON document containing its OpenID Connect and LTI-specific metadata.

Typical metadata includes:

This metadata allows the platform to automatically understand the tool’s security and functional capabilities.

4.3 Client Registration Phase

4.3.1 Platform Registration Request

After processing the tool’s metadata, the platform performs a Dynamic Client Registration request. This request conforms to the OpenID Connect Dynamic Client Registration specification and is sent to the tool’s registration endpoint.

The request typically includes:

All data is sent as a signed JSON request over HTTPS.

4.3.2 Tool Registration Response

If the registration is accepted, the tool responds with a JSON payload containing:

The client_id is stored by the platform and used in all subsequent LTI launches and service calls.

5 Privacy

Dynamic Registration enhances privacy primarily by reducing configuration errors and enforcing consistency.

1. Controlled and Transparent Capability Negotiation

During Dynamic Registration, the consumer and provider explicitly negotiate supported services, scopes, and capabilities. This ensures that:

This structured negotiation reduces the risk of unintentionally granting access to sensitive user data.

2. Principle of Least Privilege

By automating configuration, DR makes it easier to apply the principle of least privilege. Since scopes and services are defined programmatically, platforms can limit data access to what is strictly required for the tool to function. This contrasts with manual setups, where administrators may enable broad permissions to “make it work.”

3. Reduced Exposure of Sensitive Configuration Data

Manual configuration often involves copying identifiers, endpoints, and cryptographic information between systems, sometimes via insecure channels such as email or shared documents. Dynamic Registration avoids this by exchanging configuration data directly between systems over secure channels, reducing the risk of accidental data leakage.

4. Better Support for Pseudonymization

Dynamic Registration supports deployment-specific identifiers, allowing platforms to use different opaque user IDs per tool or per deployment. This makes it harder for external tools to correlate user activity across multiple contexts, thereby improving user privacy.

6 Security

LTI 1.3 relies on public-key cryptography and token-based authentication. Managing cryptographic keys manually, especially public key URLs and key identifiers, can be difficult and error-prone. Dynamic Registration simplifies this process by automatically registering the provider’s key sets and associating them with the correct client identifiers.

This automation not only simplifies the initial setup but also improves long-term maintainability. For example, when a provider rotates its keys, the consumer can retrieve updated key information without requiring a full reconfiguration by the user.

7 Contact

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

9 Discussion

Kiegel, Colin [kiegel] 2026-01-12: As a former tester of LTI 1.3 I confirm this feature is highly needed to make LTI 1.3 practical. The current manual pairing process is indeed not user friendly due to its inherent complexity. I doubt that many users would choose to adopt LTI 1.3 without this feature to improve usability. Dynamic Registration will be a game changer IMO.

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.