Lib Lti1P3 Core Laravel Package

Technical Evaluation

Architecture fit. oat-sa/lib-lti1p3-core is a framework-agnostic PHP LTI 1.3 Core library, not a Laravel package. It is best treated as a protocol adapter behind application services rather than embedded directly in controllers. A Laravel application can use it either as an LTI tool or as an LTI platform, but the role must be explicit because registration, launch validation, JWKS, and key management differ. The library’s “Core” scope is important: it should not be assumed to provide full LTI Advantage services such as AGS, NRPS, or Deep Linking unless companion packages are confirmed.

Integration feasibility. Feasible for a Laravel/PHP team through Composer and a thin service-provider/configuration wrapper. Laravel’s HTTP layer can be adapted to PSR-7/PSR-15 expectations, and Laravel’s container can bind library interfaces to application services. This is not a drop-in Laravel integration: expect custom routes, middleware, persistence, key storage, registration/deployment models, and multi-tenant configuration. A spike should validate dependency compatibility and the exact launch flow before committing.

Technical risk. The main risks are legal, security, and maintainability. GPL-2.0 is a copyleft license and must be reviewed by counsel before use in proprietary or distributed Laravel products. The package has only 37 stars, an unknown repository, and a low overall score, which suggests limited community validation and supply-chain transparency. LTI 1.3 is security-sensitive: JWT validation, nonce replay protection, JWKS/key rotation, clock skew, and tenant isolation must be implemented correctly. The opportunity score of 7.2 indicates useful domain value, but the package should be treated as an accelerator, not an unquestioned foundation.

Key questions. Which LTI role are we implementing: tool, platform, or both? Do we need LTI Advantage services beyond Core? Is GPL-2.0 acceptable for our distribution and SaaS model? Who owns upstream maintenance, security disclosure, and release cadence? Which PHP/Laravel/PSR versions and dependency constraints are supported? How are registrations, deployments, keys, and nonces persisted and rotated? What is the fallback if the library becomes unmaintained? What evidence exists for production use, test coverage, and security review?

Integration Approach

Stack fit. Use the library as a domain adapter inside Laravel: a dedicated LTI service layer, custom service provider, configuration file, and routes for login/launch/JWKS/callback flows. Keep protocol objects out of Eloquent models and controllers. Persist platform/tool registrations, deployments, key pairs, nonces, and tenant mappings in Laravel-managed tables with explicit tenant scoping.

Migration path. Start with a feature-flagged pilot against one LMS tenant and one LTI role. Build an anti-corruption layer so the library can be replaced by another LTI implementation or vendor service without rewriting business logic. If an existing LTI 1.1/1.3 integration exists, run the new path in parallel for selected courses or tools, then migrate tenant by tenant.

Compatibility. Confirm PHP version, Laravel version, PSR-7/15/17 dependencies, and whether the package conflicts with existing HTTP/JWT libraries. Validate that Laravel’s request/response objects can be bridged cleanly. Check whether required LTI Advantage features are in this package or separate OAT packages, and pin versions deliberately.

Sequencing. First complete legal/license review and a security-focused technical spike. Then implement registration and key management, followed by OIDC login/launch validation, then JWKS and key rotation, then optional Advantage services such as Deep Linking, AGS, and NRPS. Finish with multi-tenant isolation tests, replay/clock-skew tests, load tests, and a staged rollout with rollback to the existing integration.

Operational Impact

Maintenance. Expect internal ownership. The small community and unknown repository mean the team must monitor upstream releases, CVEs, PHP compatibility, and dependency drift. Pin versions, vendor the package if necessary, and maintain a fork strategy only after legal review. Avoid depending on undocumented behavior.

Support. Assume community-only support unless OAT/TAO provides a commercial agreement. Establish an internal runbook for registration failures, key rotation, JWKS fetch errors, and LMS configuration issues. Identify an LTI subject-matter expert and a security escalation path.

Scaling. LTI launch verification is generally stateless, but nonce storage, registration lookup, key management, and tenant configuration create shared-state dependencies. Use Laravel’s cache and database with appropriate TTLs, cache JWKS where safe, and design for horizontal scaling. Key rotation and multi-tenant isolation must be tested under load.

Failure modes. Common failures include invalid or stale JWKS, clock skew, nonce replay rejection, misconfigured deployment IDs, tenant crossover, missing Advantage services, dependency conflicts, and GPL compliance surprises. Launch failures are user-visible and often urgent because they block LMS access; build clear error logging and admin diagnostics without leaking tokens.

Ramp-up. Budget for LTI 1.3, OIDC, JWT/JWKS, and LMS administration learning. A PHP/Laravel developer can integrate the library, but the team also needs LMS configuration experience, security review, and legal review. Ramp-up is moderate for a spike and higher for production-grade multi-tenant operation.