OneRoster (1.2 and advanced groups)

OneRoster is an international standard for exchanging school rosters (published by 1EdTech): it describes, in a common format, a school's organizations, school years, courses, classes, enrollments and users. It is used to connect an SIS, a VLE or an LMS to another tool without re-keying data or proprietary formats.

This page is intended for the school's IT department. It describes what Omniscol exposes and consumes in OneRoster, the expected authentication, and the actual scope of each direction of exchange.

Supported versions

Omniscol supports OneRoster 1.2 Rostering — the base layer (Org, AcademicSession, Course, Class, Enrollment, User, Demographics) — as well as the OR-Groups (Advanced Groups Service) layer, the additive groups standard that adds three entities (Group, GroupMembership, GroupAssociation) on top of 1.2.

The OR-Groups layer is a standard still being published. It is strictly additive on top of 1.2: a Group only references the Class / User / Org / AcademicSession entities of 1.2, read-only. OneRoster version 1.3 is expected to make Class a specialization of Group — a direction the Omniscol implementation is already converging toward.

Omniscol as producer (Omniscol → VLE / LMS)

As a producer, Omniscol exposes the school's roster read-only, via a OneRoster-compliant REST API, for a VLE or an LMS to read.

• The Rostering 1.2 base layer is served under /ims/oneroster/rostering/v1p2/… (for example /orgs, /schools, /academicSessions, /courses, /classes, /enrollments, /users, /teachers, /students, /demographics, each with its nested variants).
• The groups layer is served under /ims/oneroster/groups/v1p0/… (/groups, /groupMemberships, /groupAssociations and their nested variants).
• The scope is the current school year by default; a parameter targets another year or covers all years.

The data reflects Omniscol's consolidated planning (active / published timetables). The producer is read-only by design: no write operation (PUT / DELETE) is exposed — a remote system does not drive the creation or deletion of entities in Omniscol.

Producer authentication

The producer endpoints are protected by OAuth2 with the client_credentials flow (a machine-to-machine token, with no user), issued by Omniscol's OAuth2 server. They are not reserved for Premium accounts: access is controlled by OAuth2 scopes, not by the plan. Each scope is specific to one service, and access to demographic data is compartmentalized within 1.2:

An OR-Groups token does not grant access to the Rostering base layer, and vice versa. No write scope is advertised. Privileged scopes are granted by the Omniscol administration when the OAuth2 client is registered; a client cannot self-assign them. OAuth2 client and token management is described on OAuth2 / OIDC (provider) and Omniscol API.

Student membership is carried by the groups layer

A structuring choice: the list of students in a class or a group is exposed via OR-Groups (GroupMembership), not by the 1.2 base layer alone. A consumer that only reads Rostering 1.2 gets the catalog (Courses, Classes), the teacher → course enrollments and the user directory, but not student membership. To know who is in which class or group, the consumer must implement the OR-Groups layer. This choice reflects the French model: a student is enrolled in a class or a group, not subject by subject.

The producer is exposed as REST. The OneRoster CSV bundle format (a zip archive with one file per collection) is supported on the import side, for providers that deliver their roster as files rather than through an API — see the consumer section below.

Omniscol as consumer (SIS → Omniscol)

French profile (school education)

The French profile for school education maps French notions onto the OneRoster model: a division (the class in the enrollment sense) becomes a Group of the main organizational type; a group becomes a Group for teaching delivery; a group of groups a cross-cutting Group; class divisions and alignments become group associations; the assignment of a teacher to a course becomes a teacher enrollment. Identifiers such as the INE or the staff identifier are carried in the user's userIds.

Identifiers and privacy

Each exposed entity carries a stable identifier, the sourcedId.

• Structural identifiers (organization, year, course, class, group) are stable and immutable from one export to the next: a consumer can rely on them to correlate data over time.
• The user identifier is anonymized: Omniscol never puts its own nominative identifier on the wire. The token put on the wire is derived by a one-way function (HMAC) specific to the account; enrollments and memberships reuse this token without ever exposing the original identifier.

Status

• Producer — available and demonstrable without a remote partner (the export stands on its own). Rostering 1.2 and the OR-Groups layer are served read-only, with OAuth2 authentication.
• Consumer — the import configuration is part of Premium synchronization. Bringing a live synchronization with an SIS into service depends on the provider and, where applicable, on ministerial calendars: it is scoped on request, connector by connector. It is not an immediate turnkey synchronization.