Lib Lti1P3 Core Laravel Package

Product Decisions This Supports

• Interoperability roadmap: build an LTI 1.3 launch path now vs. defer. This package is the protocol layer for the two highest-leverage questions an edtech PM asks: can an LMS launch our product without a custom integration? and can our platform launch third-party tools without bespoke work per vendor? It supports the decision to ship "LTI 1.3 Core" as a roadmap item scoped as a standards-conformance feature rather than a per-customer integration project.
• Build vs. buy for the protocol layer. The Core spec is deceptively small: OIDC third-party-initiated login, state/nonce handling, signed JWT launch validation, JWKS publication and key rotation, deployment/registration records, and message validation. A library decision here saves an estimated one to two engineer-months plus ongoing spec-maintenance, and — more importantly — moves the risk from "our interpretation of the spec" to "a vendor that has shipped it."
• Role decision: Platform, Tool, or both. The library explicitly supports both roles. That makes it a cheap way to prototype the "both" strategy (e.g., an LXP that is a Tool to the customer's LMS and a Platform to content partners) before committing architecture and product surface to it.
• Integration tiering and packaging. Once Core launches work, Deep Linking, NRPS (roster), and AGS (grade passback) become a sequenced, sellable capability ladder (separate lib-lti1p3-* packages) rather than one monolithic integration promise. Supports pricing/packaging decisions: "SSO/launch" in base, "roster sync + gradebook" in enterprise.
• Procurement and RFP responses. LTI 1.3 + Advantage is a gating requirement in higher-ed, K-12 district, and corporate L&D buying cycles. This underpins the decision to claim compliance on security questionnaires and tender responses, and to target 1EdTech certification as a marketing asset.
• Multi-tenant registration lifecycle. Supporting many customer LMS instances (each with its own issuer, client ID, deployment IDs, public keys) is a product feature, not a config detail. The library's registration-abstraction model shapes the admin UX decision: self-serve tool registration portal vs. ops-assisted onboarding.

When to Consider This Package

Adopt when:

• Your product is PHP/Laravel and you need to act as an LTI 1.3 Tool (launched from Canvas, Moodle, Blackboard, D2L, Sakai) or as a Platform, or both.
• You want the Core launch semantics — login initiation, JWT validation, key management — handled by code that has been exercised by a real vendor (OAT/TAO) rather than written from scratch against the spec text.
• You are prepared to own the integration shell: PSR-7/PSR-15 request/response bridging into Laravel, persistence for registrations and keys, cache for nonce/state, and the admin UI. The library is a protocol kernel, not a turnkey Laravel package; budget for adapters and tests.
• You value spec-alignment over API ergonomics, and your team can read the spec to fill gaps in sparse documentation.

Look elsewhere / escalate before adopting when:

• GPL-2.0 is disqualifying. This is the single biggest adoption blocker for a closed-source commercial SaaS or an enterprise legal review. Get counsel's read on your distribution model (server-side SaaS is usually defensible; shipping an on-prem appliance is not) before design work, not after.
• You need the full Advantage suite out of the box. Core alone does not do deep linking, rosters, or grades; confirm the sibling packages' maturity and maintenance cadence.
• Community depth matters. With ~37 stars you are adopting a low-visibility dependency: expect no StackOverflow corpus, a thin hiring signal, and a real bus-factor question. If your org requires active third-party peer review or a large contributor base, an in-house implementation or a commercially supported alternative may be the safer call.
• You are not PHP. The spec work is reusable knowledge, but the code is not; other-language libraries or a polyglot service are the equivalent decision.
• The requirement is only "SSO for one customer." A single bespoke integration may be cheaper and lower-risk than adopting a standard you will not reuse.
• Certification is a hard near-term requirement. Verify your planned version supports the 1EdTech conformance test suite before committing; do not assume the library alone gets you a certification pass.

Confidence note: the opportunity score (7.2) is modest — the market need is real and durable, but the library's own adoption signal is weak. Treat this as "technically credible, commercially thin."

How to Pitch It (Stakeholders)

For executives: LTI 1.3 is the standard that lets our customers launch our product from their learning platform — and lets us launch partners' tools — without one-off engineering per account. Using an existing library instead of writing the protocol ourselves compresses a multi-month build into an adapter effort, and it lets us answer "yes" on interoperability in RFPs and security reviews. The strategic value is not the code; it is the sales gate it removes and the partner integrations it unlocks. Caveat to surface now: the license is GPL-2.0 and the community is small, so this requires a legal ruling and a maintenance owner before we commit. Recommend a two-week spike: build one Tool launch against a Moodle/Canvas test instance, get legal's read on GPL, and return with a cost estimate for the full Advantage roadmap.

For engineering: This is a protocol kernel, not a Laravel package. It gives us JWT signing/validation, OIDC login flow, JWKS, and registration abstractions, and it expects us to supply the PSR-7/PSR-15 bridge, the persistence layer for registrations and keys, nonce/state caching, and the admin surface. It is well-factored and follows the spec closely; documentation is thin, so plan for spec-reading time. Sibling packages cover Deep Linking, NRPS, and AGS. Risk: low maintainer diversity — we should vendor-lock the version, add our own integration test suite against real LMS instances, and be ready to fork.

For product/GTM: Positions us as standards-compliant (LTI 1.3 Core; Advantage as a fast follow), enables "works with your LMS" messaging, and creates a natural enterprise tier for roster sync and grade passback. Pair the release with 1EdTech certification to convert an engineering task into a procurement checkbox.

Ask: approve a timeboxed spike (legal + one working launch) with a go/no-go on GPL and on owning the integration shell.