Dynamic Registration as a Provider

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 provider form

As an LTI tool, ILIAS exposes a registration endpoint that external platforms use to start Dynamic Registration.

The form of an LTI Advantage platform in Administration > LTI > ILIAS as LTI Tool (Provider) > Platforms (Consumers) shows the Dynamic Registration URL of ILIAS for that platform.

Administrators copy this URL into the platform to start the registration.

This URL:

• Is the entry point for external platforms to start Dynamic Registration
• Points to the registration endpoint of ILIAS, which reads the OpenID configuration of the platform
• Is easy to find and copy for 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

An administrator creates the platform in Administration > LTI and copies its Dynamic Registration URL into the platform. The platform opens this URL in the browser of its user, adding the URL of its OpenID configuration and, optionally, a registration token. This URL is the only value the user enters manually.

4.2.2 Retrieval of Platform Metadata

ILIAS sends an HTTPS request to the OpenID configuration URL of the platform. In response, the platform provides a JSON document containing its OpenID Connect and LTI-specific metadata.

Typical metadata includes:

This metadata tells ILIAS where to send its registration and how the platform authenticates launches and service calls.

4.3 Client Registration Phase

4.3.1 Tool Registration Request

After processing the metadata of the platform, ILIAS performs a Dynamic Client Registration request. This request conforms to the OpenID Connect Dynamic Client Registration specification and the LTI tool configuration, and is sent to the registration endpoint of the platform, with the registration token of the platform if it gave one.

The request of ILIAS includes:

The request is sent as JSON over HTTPS.

4.3.2 Platform Registration Response

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

ILIAS stores the client id and the deployment id with the endpoints of the platform as the registration of that platform, and uses them 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.

The data ILIAS exchanges and stores through Dynamic Registration is described in the PRIVACY.md of the LTI component.

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

Author of the Request: Santiago, Sergio [sergiosantiago02]
Maintainer: Díaz, Saúl [sdiaz]
Implementation of the feature is done by: Díaz, Saúl [sdiaz]

8 Funding

This feature is funded by Leibniz Universität Hannover. We thank the university for supporting its development.

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.

Kruse, Fabian [Fabian], 26.01.2026: As both the test manager and a former tester of LTI 1.3, I second Colin’s remarks. This improvement should vastly improve usability and should be introduced as soon as possible in supported versions of ILIAS. 

Díaz, Saúl [sdiaz], 20 OCT 2026: The implementation is included in the LTI rework for ILIAS 12: https://github.com/ILIAS-eLearning/ILIAS/pull/12232. The pull request is open for review.

Díaz, Saúl [sdiaz], 23 OCT 2026: The pull request has been merged into trunk.

10 Implementation

Feature has been implemented by Díaz, Saúl [sdiaz] as part of the LTI rework for ILIAS 12.

10.1 Description and Screenshots

The implementation is available in pull request #12232: https://github.com/ILIAS-eLearning/ILIAS/pull/12232. It was merged into trunk on 23 OCT 2026.

Implemented as described in the Conceptual Summary and User Interface Details. Administrators create an LTI Advantage platform in Administration > LTI > ILIAS as LTI Tool (Provider) > Platforms (Consumers) and copy its Dynamic Registration URL into the external platform. The existing screenshot in section 3.2 shows where this URL is provided.

ILIAS retrieves the OpenID configuration of the platform and submits its tool registration. On success, it stores the assigned client id and deployment id with the platform endpoints for subsequent launches and service calls. Administrators do not need to copy those parameters manually. Existing registrations remain available after the regular ILIAS update; no manual migration is required.

10.2 Test Cases

Test cases completed at 23 OCT 2026 by Díaz, Saúl [sdiaz]

C96407 : Register ILIAS in Moodle by Dynamic Registration
C96408 : Register ILIAS in another ILIAS by Dynamic Registration
C96409 : Dynamic Registration URL used once; registration of another platform refused
C96400 : Edit a platform: an incomplete registration is refused

10.3 Privacy

The PRIVACY.md of the LTI component was updated on 20 OCT 2026 by Saúl Díaz. It documents the configuration data exchanged and stored through Dynamic Registration. The update is included in pull request #12232, merged into trunk on 23 OCT 2026: https://github.com/ILIAS-eLearning/ILIAS/blob/trunk/components/ILIAS/LTI/PRIVACY.md.

10.4 Approval

The feature was accepted for trunk by the Jour Fixe on 26 JAN 2026 (see Discussion). Approval of the delivered implementation has not yet been recorded.