The problem
A child sits down to learn. To get through a single afternoon they bounce between a tutor, a reading app, a math game, and a literacy coach — each with its own login, its own onboarding, its own dashboard. The kid forgets passwords. The parent re-enters them. The teacher has no consolidated view of what's actually being learned.
And nobody can answer the basic question: what did my child do today? Each app keeps progress in its own silo, in its own shape, behind its own export. There is no standard place a parent or teacher can look to see learning progress across the apps a child uses.
OLP is a small set of specs that addresses both ends of that problem: a way for a host environment to hand identity to a learning app without yet another login, and a way for learning apps to report progress in a shape any dashboard can read. Short, opinionated, with reference code. The goal is interop. The non-goal is to model pedagogy.
See it in motion
A reference launcher opens a tutor with one click. No login form, no password — the launcher mints a token, the tutor verifies it, the child is in.
Specs
The launcher already knows the child. EduSSO hands that identity to the learning app in one signed JWT — about ten lines of code on the app side.
The learning app knows what the child did. EduProgress emits structured progress events to a collector, so progress is portable across apps and dashboards.
Principles
| Small over expressive | Every spec fits in a single read. We'd rather force product decisions outside the protocol than encode them inside it. |
|---|---|
| Independently implementable | Each spec stands alone. You can adopt one without the others. They compose when you want them to. |
| Reference code, not just text | Every spec ships with a working example. If you can't make the example talk to your implementation in an afternoon, the spec is wrong. |
| Vendor-neutral | No registration, no central authority, no required services beyond what the protocol itself defines. |
Status
Each spec is currently at draft v1. The text is written, reference code exists. The next step is real integrations, which is where the specs will either earn the right to call themselves v1 stable or change in obvious ways.
If you're implementing one of these, please tell us. Open an issue or send a PR.
Contribute
Editorial fixes go straight to pull request. Substantive changes go through an RFC. Governance, license, and contribution rules live in the repository.
