The Madigan Library at Penn College defines technical specifications as:

A technical [specification] is an established norm or requirement about technical systems. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices.

Specifications like OneRoster ensure that different systems, such as SIS and edtech platforms, work together without complications, making technology integration smooth for learning institutions. Well-known examples include Apple’s operating system, NEMA connectors (for household plugs), and USB ports. We all benefit from the ways these specifications allow different technologies to communicate and work together.

Understanding OneRoster and the Interoperability Challenge

OneRoster was developed by 1Edtech, a non-profit focused on improving data interoperability in education. In this context, interoperability means different software systems can:

  • Communicate with each other,
  • Exchange data, and
  • Reduce manual processes and errors.

Interoperability is critical for educators, as it provides a more complete view of student learning, enabling personalized learning.

In edtech, there are only two types of integrations: API integrations and specification-based integrations – like OneRoster and LTI (more on LTI integrations here). For SIS-specific integrations, edtech developers have a few methods to choose from:

  • using an education specification, like OneRoster,
  • building a custom integration to the SIS provider’s API, or
  • connecting to an aggregator like Edlink

Essentially, OneRoster is one integration method that lays out how to implement the specification; it tells you how to “build the bridge” between one system to an SIS. From the view of edtech companies, this is where the interoperability problem begins.

To excel in learning institutions RFPs, and to deliver superior experiences, effective SIS interoperability is valuable. However, to become interoperable, edtech companies tend to continuously throw resources into their builds like:

  • wasting months of product timeline,
  • hiring an integration manager, and/or
  • spending thousands of dollars in development time.

And if the integration does get built, the resource-wasting “interoperability game” never stops. Often, integrations are incomplete or limited in functionality, requiring further development. In other cases, institutions may sync all of their data, but the product might be unable to filter the fields it needs. Even simple troubleshooting can become too complex, necessitating the hiring of additional developers. There’s always another SIS to integrate with or another connection to manage.

In our experience, we’ve encountered challenges with SIS integrations, too:

  • Some SIS providers only allow third-party vendors to use OneRoster integrations.
  • Some SIS providers require you to pay for a test instance or limit access to their documentation.
  • Some SIS providers lack sufficient technical support or are too slow to respond.
  • Some SIS providers have significant functional limitations, like allowing read access but not write access.

Regardless of which challenge(s) edtech developers face within SIS interoperability, it is a fact that there will always be something.

Benefits vs. Limitations

When edtech companies successfully integrate with an SIS, it enables their product to perform valuable functions, such as:

  • provisioning accounts automatically and ahead of the school year (known as “rostering”)
  • sharing learning outcomes to a learning institution’s gradebook automatically
  • retrieving attendance data for analysis
  • … and more!

Because schools use many different edtech products, they require solutions that (1) are interoperable and (2) seamlessly share data. These capabilities make an edtech product more appealing and harder to replace (i.e., “sticky”), leading to happier customers and higher renewal rates.

However, all technical specifications come with some limitations. For example,

  • Android-only apps can’t upload to the Apple app store,
  • NEMA connectors in the U.S. differ from those in Spain,
  • USB drives are not compatible with USB-C ports.

OneRoster is the same way. 1Edtech designed OneRoster to share class rosters, course materials, and grades. Even though SIS providers store many other types of data (such as facilities or period data), OneRoster isn’t designed to work with these fields. Developers must follow the specification closely to implement it correctly, which can be confusing.

To establish a OneRoster connection, developers might need to implement several different versions of the standard, like OneRoster 1.1, which supports OAuth 2.0, OAuth 1.0, or CSV file transfers. This is because the chosen implementation must match the SIS provider’s preferred method. Unlike API integrations, where the build is tailored to the product, OneRoster integrations aren’t customized.

Probably the largest (and most controversial) limitation of specifications like OneRoster is that they are reactive rather than proactive. OneRoster isn’t innovative; its focus isn’t to “find the best SIS integration method”. When a new version of a specification is released, the older version is often quickly deprecated, regardless of how many edtech companies or SIS providers are still using it.

On the other hand, developers can benefit from OneRoster. It’s widely recognized, and integrating with SIS providers can sometimes be more straightforward. OneRoster uses modern mechanics (OAuth, JSON) that are familiar, secure, and well-known. If a product needs an efficient way to access class rosters, course materials, and grade information, OneRoster could be a good solution.

Changes between OneRoster 1.1 and 1.2

After going through the OneRoster 1.2 documentation from 1EdTech, these are the key differences we noticed (some points are taken directly from the documentation):

  • Uses 0Auth 2.0 Bearer Token exclusively
  • Adds 3 new name properties from for users who wish to be called by a different name than their legal name; preferredFirstName, preferredMiddleName, and preferredLastName
  • Supports users who have multiple roles within one or several organizations

The 'roles' class has been added to enable the assignment of any combination of role/org/account mappings for a user including date stamping to enable partial academic sessions.
The roles attribute has been added to the 'user' class.
The role attribute has been removed from the 'user' class.
The orgs attribute has been removed from the 'user' class.
The primaryOrg attribute added to the 'user' class.

  • Updates the Gradebook Service to support Standards-Based Grading
  • Adds the weighting scheme the organization or teacher designed to copy to the new system – supporting score scaling with grades
  • Adds a new attribute to store non-numeric scores: textScore
  • Adds a new endpoint for those with unique gradebook categories for each class: getCategoriesForClass
  • Limits access to data within an endpoint through scoping down

These changes impact rostering…

  • Reorganizes Rostering into its own Service Model with newly annotated endpoint: /ims/oneroster/rostering/v1p2
  • Extends the vocabulary of the attribute sex with the tokens 'other' and 'unspecified'
  • Adds attribute userMasterId to the “User” class to enable a definitive globally unique identifier (not the interoperability sourcedId for the user)
  • Adds attribute roles to the “User” and “Roles” classes to enable the combination of role/org/account mappings for a user
  • Adds the resources attribute to “User” to identify resources available to the user
  • Removes the role and orgs attributes from “User” class
  • Adds primaryOrg to the “User” class
  • Adds masterProfiles attribute to the “User”, “UserProfiles”, and “Credential” classes to enable assignment profiles to a user
  • Makes the following extensible for easier profiling and internationalization: ClassTypeEnum, GenderEnum, OrgTypeEnum, RoleEnum' and 'SessionTypeEnum'
  • Removes CEDS/SCEDS vocabulary in order to be replaced by more relevant (by geographic region) vocabulary
  • Requres Service Provider to make a localized OpenAPI file available for Service Discovery

To Recap

OneRoster 1.2 is the latest version of the specification. Key changes include:

  • adding new attributes to expand the depth of information tied to a user,
  • making rostering its own service, and
  • moving to OAuth 2.0 for authentication.

OneRoster 1.2 is tied deeply to the interoperability problem. Learning institutions need interoperable edtech products but building this functionality is resource-heavy for companies. While OneRoster 1.2 can improve interoperability, integrating with it requires careful consideration of the product’s context, the development team’s capacity, available resources, the SIS provider’s requirements, and the needs of the product's end users.

Read More on Data Standards

Here are other resources on Data Standards and Edlink to help you on your integration journey:

Want to Get Started?

If you're looking for a partner to guide you through developing integrations, then let us introduce ourselves. We're Edlink!