Contributed by Dr. Colin Smythe, 1EdTech Chief Architect
OneRoster® 1.2: Final Release Publication of the Latest Version of the 1EdTech Rostering, Resources & Gradebook Standards
In September 2022, 1EdTech published the OneRoster 1.2 standard. OneRoster is designed to support three use-cases:
- Rostering of students in classes;
- Rostering of users for access to learning resources;
- Reporting of gradebook information.
We published OneRoster 1.0 in June 2015. This release focused on the exchange of rostering, Enrollments, of Users (Teachers and Students) in Classes at Schools but included a limited capability to exchange gradebook data. Even in this first release, there was support for both a REST-based API and CSV-based file exchange. OneRoster 1.0 was an immediate success and, typical of such success, a long list of limitations was identified, so work on version 1.1 was started.
Version 1.1, published in April 2017, included a substantial set of new features:
Extending the data model for the description of a User;
Support for identifying the set of Resources that need to be made available for a specific Class and/or Course;
Providing a data creation and deletion capability for the gradebook information, i.e., the Category, LineItem, and Result;
Adding the optional usage of OAuth 2 for the REST API binding definition.
We began work on OneRoster 1.2 in April 2017. The primary drivers for the new features were to:
Allow a User to have multiple Roles in more than one Organization;
Enable the identification of the set of Resources to be made available to a specific User;
Enable, for the Gradebook, the exchange of Score Scales, the mapping of results to the corresponding set of learning standards, and support detailed results reporting;
Provide a richer set of Gradebook Service endpoints to enable a Consumer to write information (push) into a Provider;
Break the REST-API specification into its three service components of rostering, resources, and gradebook, to simplify the adoption of part of the OneRoster specification.
Unusual for 1EdTech, the OneRoster specification consists of two information exchange (binding) approaches, CSV and REST API.
CSV-based exchange uses a zipped file of the set of CSV files. In OneRoster 1.0, the interoperability consisted of just seven CSV files and 38 REST endpoints; in OneRoster 1.1, this became 14 CSV files and 61 REST endpoints; for OneRoster 1.2, it is 22 CSV files and 81 REST endpoints.
For CSV file exchange, there are two approaches:
Bulk – the exchange of a complete data set, i.e., one that is semantically complete. This is to be interpreted as the creation of a OneRoster data-set or a destructive overwrite of the previously stored data-set;
Delta – the exchange of ONLY those data records that have changed since the previous exchange.
The expected behavior for CSV-based systems is initialization using Bulk exchange followed by a sequence of Delta update exchanges. The specification is silent on how the CSV files are exchanged. For the REST-API definitions, three sets of OpenAPI and JSON Schema files are supplied to simplify the creation and validation of Provider and Consumer implementations.
Other changes that have been made as the specification has evolved are:
Whereas the use of OAuth 1.0a message signing was required in OneRoster 1.0, OAuth 2.0 Bearer Token (Client Credentials) is required in OneRoster 1.1 and 1.2. In July 2021, support for OneRoster 1.0 was deprecated. Therefore, only OneRoster 1.1 and 1.2 are available for adoption and certification.
More extension features have been introduced to improve internationalization and localization (identified by the use of OneRoster in Japan and Norway). For example, in OneRoster 1.2, most of the enumerated vocabularies may be extended.
In OneRoster 1.0, only pull REST endpoints were permitted but in OneRoster 1.1 and 1.2, support for pull and push REST endpoints was introduced for the Gradebook Service.
Splitting the REST-API solution into three distinct services has increased the range of available certifications. The set of certifications now available are:
CSV Import and CSV Export. All certifications must support the exchange of Bulk-Rostering exchange. Support for Bulk-Resources and Bulk Gradebook exchange is optional. Support for Delta-Rostering, Delta-Resources, and Delta-Gradebook exchange is asl optional. A OneRoster CSV Validator for export certification and a set of OneRoster Reference Test Set Files for import certification are available to 1EdTech members.
REST API Provider or REST API Consumer. At least one of the following services must be supported: Rostering, Resources, Gradebook, Assessment Results. For each of these services, there is a minimum number of endpoints that MUST be supported, support of the others being optional. Separate Provider Certification and Consumer Certification conformance test systems are available to 1EdTech members.
This creates many possible certifications that can be awarded to a product. Therefore, two OneRoster-certified products are NOT guaranteed to be interoperable. You must read and compare the accompanying certification descriptions to understand the degree of interoperability.
ONEROSTER IN THE 1EDTECH ECOSYSTEM
OneRoster is a key component in many 1EdTech Ecosystems. The relationships between OneRoster and other 1EdTech standards are:
Learning Tools Interoperability® (LTI®) Advantage – The LTI Names & Roles Provisioning Services and Assignment and Grade Services extensions have overlapping functionality with OneRoster. However, these LTI and OneRoster services complement each other—LTI handles real-time interactions with an LTI-enabled tool/app and OneRoster supports the data initialization and archiving between another system and an LTI-enabled platform.
Competencies & Academic Standards Exchange® (CASE®) – The CASE Globally Unique Identifiers contained in the descriptions of the Resources to be made available to a Class, Course and/or User are used to identify the set of competencies and academic standards applied to that resource.
Question & Test Interoperability® (QTI®) – The overlap is between the QTI Results Reporting part of the QTI specification and the Assessment Results part of the OneRoster Gradebook Services. The latter enables QTI Results Reporting level of detail to report to a Student Information System, enabling more detailed results reporting in a gradebook.
Common Cartridge® and Thin Common Cartridge – The vendorResourceId property for a Resource can be used to map to the equivalent resource being exchanged in a Common Cartridge and/or Thin Common Cartridge. It should be noted that this requires the appropriate content identification planning and management by the vendor.
Edu-API – At present, this specification work is focused on creating a OneRoster equivalent for use in higher education. The data model for Users, Classes, Courses, and Enrollments is considerably more complex in higher education, so the simple adoption of OneRoster is not possible.
The original OneRoster 1.0 version was designed to support K-12 districts/schools rostering in North America.
OneRoster 1.2 has been designed for use around the world. Work in Japan and Norway is already underway on the Profiling of OneRoster 1.2 to fit the specific needs of their K-12 education systems. A 1EdTech specification is defined to support a wide range of teaching and learning workflows and processes. It enables practice.
Profiling is the process by which a base specification is modified to enforce best practices specific to an education sector and/or geographic location. The advantage of profiling is that the corresponding modified conformance and certification systems and processes are created such that a product can be certified with respect to a Profile, thereby significantly improving, perhaps guaranteeing, interoperability.
After working for more than seven years on creating and developing the OneRoster specification, it is time to focus on supporting broader adoption.
The 1EdTech member community has no plans to work on a OneRoster 1.3 version. It is more likely that any new version will be defined as a formal Profile of the Edu-API specification, but even this is many years away.