Migrated from upstream issue lti-tool#122: lti-tool#122
Original created at: 2026-06-04T14:38:07Z
Background
LTI 1.3 is built on OpenID Connect, JWT/JWS, and OAuth 2.0 style security flows. Public 1EdTech material appears to point more toward tracking OAuth 2.1 alignment than toward adopting OAuth 2.0 Pushed Authorization Requests (PAR, RFC 9126) as an LTI launch requirement.
OAuth 2.1 primarily consolidates OAuth 2.0 security best practices and removes or discourages weaker legacy behavior. For LTI, the relevant work is likely to be confirming that this library's OIDC launch, token, client-authentication, and dynamic-registration behavior remains compatible with the direction of OAuth 2.1 and current 1EdTech Security Framework guidance.
Why Track
As OAuth 2.1 matures, LMS platforms and institutional security reviews may increasingly describe requirements using OAuth 2.1 terminology even when the underlying LTI behavior still follows the existing LTI 1.3 and 1EdTech Security Framework specifications.
This library should have a clear compatibility story for OAuth 2.1-era expectations without adding speculative launch behavior that current LTI platforms do not require.
Possible Implementation Shape
- Audit current OIDC launch and token flows against OAuth 2.1 security expectations.
- Confirm no unsupported OAuth legacy flows are exposed or implied by the public API.
- Document how LTI 1.3 launch, client assertion, token exchange, and dynamic registration map to OAuth 2.1-era terminology.
- Review redirect URI, state, nonce, issuer, audience, deployment, and client ID validation for any OAuth 2.1-relevant gaps.
- Review token endpoint authentication behavior, especially private key JWT/client assertion handling.
- Add tests for any OAuth 2.1-alignment gaps found during the audit.
- Keep existing LTI 1.3 behavior compatible by default.
Non-Goal
Do not add PAR support solely on speculation. PAR should remain out of scope unless an LTI platform, 1EdTech profile, or concrete integration requirement exposes pushed_authorization_request_endpoint metadata or requires PAR-like launch behavior.
Acceptance Criteria For A Future PR
- The repository documents the current OAuth 2.1 alignment position for LTI 1.3 flows.
- Any discovered OAuth 2.1-relevant validation gaps have tests and fixes.
- Existing LTI 1.3 launch behavior remains unchanged unless a specific compatibility issue is found.
- PAR is not implemented as part of this issue unless a concrete LTI requirement is identified.
Migrated from upstream issue lti-tool#122: lti-tool#122
Original created at: 2026-06-04T14:38:07Z
Background
LTI 1.3 is built on OpenID Connect, JWT/JWS, and OAuth 2.0 style security flows. Public 1EdTech material appears to point more toward tracking OAuth 2.1 alignment than toward adopting OAuth 2.0 Pushed Authorization Requests (PAR, RFC 9126) as an LTI launch requirement.
OAuth 2.1 primarily consolidates OAuth 2.0 security best practices and removes or discourages weaker legacy behavior. For LTI, the relevant work is likely to be confirming that this library's OIDC launch, token, client-authentication, and dynamic-registration behavior remains compatible with the direction of OAuth 2.1 and current 1EdTech Security Framework guidance.
Why Track
As OAuth 2.1 matures, LMS platforms and institutional security reviews may increasingly describe requirements using OAuth 2.1 terminology even when the underlying LTI behavior still follows the existing LTI 1.3 and 1EdTech Security Framework specifications.
This library should have a clear compatibility story for OAuth 2.1-era expectations without adding speculative launch behavior that current LTI platforms do not require.
Possible Implementation Shape
Non-Goal
Do not add PAR support solely on speculation. PAR should remain out of scope unless an LTI platform, 1EdTech profile, or concrete integration requirement exposes
pushed_authorization_request_endpointmetadata or requires PAR-like launch behavior.Acceptance Criteria For A Future PR