Skip to main content

Security Framework

Trusted Exchange of Student Data  

CIOs, CSSOs, and Data Protection Officers have critical security-related concerns about sensitive and personally identifiable information (PII) passing between platforms and tools. Older security frameworks have demonstrated vulnerabilities.Security Framework 1EdTech members are leading the drive to improve student privacy and security by adopting the 1EdTech Security Framework across its standards.  

1EdTech creates service-oriented and message-exchange interoperability specifications. These service-based specifications recommend or require many different security patterns: for example, the use of OAuth 1.0 based message signing, OAuth 2.0 based authentication and authorization, and so forth. The Security Framework defines a set of patterns for security that all 1EdTech specifications should use (only in special circumstances will 1EdTech consider exceptions). These security patterns are premised on the appropriate standards and specifications published by other organizations such as the Internet Engineering Task Force (IETF) and its Requests For Comments (RFCs). The core standards used are:

  • OAuth 2.0 - RFCs 6749 and 6750 from the IETF
  • JSON Web Tokens - RFCs 7515, 7516, 7517, 7518, 7519 and 7523
  • Open ID Connect Core - an identity layer, from OpenID Foundation, on top of OAuth 2.0

The use of the Security Framework promotes consistent and compatible implementation requirements and simplifies adoption when more than one 1EdTech specification is being implemented.

In the case where 1EdTech has defined a web services-based standard, such as OneRoster, the specification will describe the set of web service calls that can occur between a service consumer (or Client) and a service provider (Platform). Typical service calls include when a Client 'pulls' the data from the Platform and when the Platform 'Pushes' the data to the Client. In many cases, these service calls must occur within an appropriate security framework. For 1EdTech specifications using a web services approach, the Figure on the right shows a schematic representation of this security framework

The specification will define how the Client and Platform will exchange information. This document defines how to achieve the "Authentication" and "Authorization" using a separate set of message exchanges and how the actual corresponding set of 1EdTech service calls will use this authorization and authentication information. The authorization and authentication use an "Authorization Server" which may be a system independent of the Platform or may be endpoints hosted by the Platform.

In the case where 1EdTech has defined a non-web services based standard, such as Learning Tools Interoperability (LTI), the specification will describe the set of messages that can occur between a Platform and a Client. In scenarios where the message exchange is vulnerable (for example, when launching from a web browser), the messages will be signed. This signing MAY include data derived from the identity-based authentication. The 1EdTech specification defines how a Client can transform the messages exchanged between the Platform and the Client (including a user's browser-based interaction) into a Client-based experience. This document defines how to achieve Authentication and Authorization using a separate set of message exchanges between Platform and Client and how to encode the authorization and authentication information in JWT-based message signing of these message exchanges. The authorization and authentication process uses an authorization server which may be a system independent of the Platform or may be endpoints hosted by the Platform.

The Security Framework was published as Final Release to the public in May 2019. It is upon this framework that all 1EdTech service-based specifications should make reference, including the LTI 1.3 and LTI Advantage services.

Member Resources

Public Resources

Security Framework

Security Updates

Help us improve the accessibility of this site by emailing recommendations to web@imsglobal.org