Trusted Exchange of Student Data
CIOs, CSSOs and Data Protection Officers have critical security-related concerns about sensitive and personally identifiable information (PII) being passed between platforms and tools. Older security frameworks have demonstrated vulnerabilities. IMS Global members are leading the drive to improved student privacy and security by adopting this IMS Security Framework across its standards.
IMS Global has created, is creating, and will continue to create, service-oriented and/or message-exchange interoperability specifications. These service-based specifications recommend or require a number of different security patterns: for example, the use of OAuth 1.0 based message signing, OAuth 2 based authentication and authorization, and so forth. The IMS Security Framework defines a set of patterns for security that all of its specifications should use (only in special circumstances will IMS consider exceptions). These security patterns are based on the appropriate standards and specifications published by other organizations, for example 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 IMS Security Framework promotes consistent and compatible implementation requirements and simplifies adoption when more than one IMS specification is being implemented.
In the case where IMS 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 IMS specifications using a web services approach, the Figure on the right shows a schematic representation of this security framework
The IMS 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 IMS service calls will use this authorization and authentication information. The authorization and authentication uses an "Authorization Server" which may be a system independent of the Platform or may be endpoints hosted by the Platform.
In the case where IMS 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 IMS 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 IMS Security Framework is currently a Candidate Final document available to IMS members only. It is upon this framework that all IMS service-based specifications should make reference, including the LTI v1.3 and LTI Advantage services.
Member Resources (login required)
- IMS Security Framework v1.0 - Candidate Final status (updated 25th July, 2018)