OneRoster vs LTI®
The short answer
They are not alternatives. OneRoster moves roster data between systems — who exists, which class they are in — usually out of a student information system, in bulk, on a schedule. LTI® launches a person into a tool from inside a course, live, one click at a time.
Both are published by 1EdTech Consortium, Inc., which is most of why they end up compared — OneRoster and LTI® each have their own specification.
The distinction that decides it
Ask when you need to know about a person.
Before they arrive — you are provisioning accounts, building class lists, preparing content, or reporting on people who have not logged in — that is OneRoster's job.
When they arrive — you need to know who is at the door, what course they came from, and what role they hold — that is LTI®.
| OneRoster | LTI® | |
|---|---|---|
| Answers | Who exists, and in which class | Who is here now, and from where |
| Source | Usually the SIS | The LMS |
| Timing | Bulk, scheduled or on demand | Live, at the moment of a launch |
| Scope | An institution | One course, via one launch |
| Carries grades | Yes, gradebook exchange | Yes, per activity |
| Launches anything | No | Yes — that is the point |
But LTI® has a roster service
This is where the comparison gets muddled, and it is a fair question: Names and Roles reads the list of people in a course. So when is that not enough?
Three cases.
You need more than the course you were launched from. Names and Roles is scoped by the launch — one context, and only after somebody has launched at all. OneRoster covers the institution whether or not anyone has clicked anything.
You need it before first contact. Provisioning accounts ahead of term, or sending an email to people who have not used the tool yet, needs data that arrives without a launch.
The authoritative source is the SIS, not the LMS. In many institutions the LMS is downstream of the student records system, and its enrolments lag. If you need the truth rather than the LMS's copy of it, you need the upstream system.
If none of those apply, Names and Roles is enough, and it is far less work.
The organisational cost
Worth being plain about, because it changes the decision more than the technical comparison does.
LTI® is agreed with whoever administers the LMS. Often one person, often the same person who wanted your product.
OneRoster reaches into the student information system, which is a different team, usually more cautious, and running the system that holds the institution's authoritative student data. The conversation is longer, involves data protection, and is frequently the reason a rostering project takes a term rather than a week.
That asymmetry is why "we support LTI®" is a sales feature and "we support OneRoster" is a procurement conversation.
Choosing
Implement LTI® first. It is what makes your product reachable from inside a course, and without it a rostered account has nowhere to log in from. Its roster service covers most of what people initially want OneRoster for.
Add OneRoster when customers ask for institution-wide provisioning — accounts before term, coverage of people who never launch, or an authoritative source your LMS integration cannot give you.
Do both if you sell to districts, where rostering is often a procurement requirement in its own right and the LMS is one system among several.
The honest summary: most products need LTI®, some products also need OneRoster, and very few need OneRoster alone.
Where LTIAAS fits
LTIAAS covers the LTI® side, including the roster service — reading course membership, with roles and whatever personal data the platform releases. It does not implement OneRoster, which is a separate integration with a different system.
If your requirement is "read the class I was launched from", Names and Roles is the answer and you already have it. If it is "provision every student in the district before term", that is a OneRoster project and LTI® is what those accounts will launch through.
Common questions
What is the difference between OneRoster and LTI®?
OneRoster moves roster and enrolment data between systems, typically from a student information system, in bulk and on a schedule. LTI® launches a user into a tool from within a course. One is data movement, the other is a live launch.
Do I need OneRoster if I have LTI®?
Only if you need data about people before they arrive. LTI® tells you about whoever launched, and its roster service covers the course they came from. OneRoster covers a whole institution ahead of time.
Is OneRoster a replacement for Names and Roles?
No. Names and Roles reads one course, live, scoped by the launch. OneRoster covers an institution, in bulk, usually on a schedule and usually sourced from the SIS rather than the LMS.
Which should I implement first?
LTI®, in nearly every case. It is what makes your product reachable from inside a course, and it comes with a roster service that covers most needs. Add OneRoster when customers ask for institution-wide provisioning.
Next
- How LTI® roster access works — what you get without OneRoster
- SCORM vs LTI® vs xAPI vs cmi5 — the other standards comparison
- What is LTI® 1.3?
