IMS Data Privacy

IMS Data Privacy

IMS Final Release
Version 1.0
IMS Final Release
Date Issued: July 12th, 2020
Status: This document is made available for adoption by the public community at large.
This version: https://www.imsglobal.org/spec/privacy/v1p0/
Latest version: https://www.imsglobal.org/spec/privacy/latest/
Errata: https://www.imsglobal.org/spec/privacy/v1p0/errata/

IPR and Distribution Notice

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

The following participating organizations have made explicit license commitments to this specification:

Org name Date election made Necessary claims Type
D2L July 6, 2020 No RF RAND (Required & Optional Elements)
Washington State Board for Community and Technical Colleges (WSBCTC) July 6, 2020 No RF RAND (Required & Optional Elements)
Gwinnett County Public Schools July 14, 2020 No RF RAND (Required & Optional Elements)

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/speclicense.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/ims-glc-public-forums-and-resources.

© 2020 IMS Global Learning Consortium, Inc. All Rights Reserved.

Trademark information: http://www.imsglobal.org/copyright.html

Executive Summary

Educational applications provide content and tools to help students learn. Educational applications are created and managed by suppliers. Suppliers manage the identity of the individuals accessing the system and the data that they generate. However, there are many factors that need to be considered to ensure that each application used by institutions is appropriate for students. The student’s privacy, data security, or other safety considerations implemented by suppliers when developing educational tools may not match the needs of an institution; thus, it is the responsibility of the institution to ensure required student data safeguards are in place.

Educational institutions are required to ensure suppliers meet their students’ privacy, data security, and other safety considerations. This has created an environment where institutions are vetting applications independently of other institutions, often with their own unique but similar questions. This separate and independent evaluation places a burden on institutions and suppliers to timely and cost-effectively adopt new technologies. This Data Privacy specification provides suppliers a method to communicate their policies and practices in a consistent format. Institutions can leverage this information, reducing the time, manpower, and cost required to vet applications while ensuring all considerations are consistently met. Within the rubric, IMS has identified four core areas that provide assurances that the information gathered by suppliers is being used responsibly:

  • Data Collected - covers data the supplier collects as the user interacts with the app. This data could include information provided by the user explicitly as well as information collected by the app during its use. This area concerns who owns the data, what right the user has to have their data deleted, and how long an app supplier may retain the data;
  • Security - covers all of the supplier's back-end security policies and practices. Specifically, it addresses data protection practices, handling of confidential and sensitive information, authentication, and use of cookies;
  • Third-Party Data Sharing - covers all 3rd party interactions with the supplier and with the user’s data. This section also addresses the sharing of user data with 3rd parties;
  • Advertising - covers how the supplier manages advertisements and whether or not there is advertisement targeting or tracking.

1. Introduction

1.1 Scope and Context

1.1.1 Context

Educational applications provide content and tools to help students learn. Educational applications are created and managed by suppliers. Suppliers manage the identity of the individuals accessing the system and the data that they generate. However, there are many factors that need to be considered to ensure that each application used by institutions is appropriate for students. The student’s privacy, data security, or other safety considerations implemented by suppliers when developing educational tools may not match the needs of an institution; thus, it is the responsibility of the institution to ensure required student data safeguards are in place.

Educational institutions are required to ensure suppliers meet their students’ privacy, data security, and other safety considerations. This has created an environment where institutions are vetting applications independently of other institutions, often with their own unique but similar questions. This separate and independent evaluation places a burden on institutions and suppliers to timely and cost-effectively adopt new technologies. This App Vetting Rubric specification provides suppliers a method to communicate their policies and practices in a consistent format. Institutions can leverage this information, reducing the time, manpower, and cost required to vet applications while ensuring all considerations are consistently met.

IMS has published an extensive set of EdTech Interoperability Standards including Common Cartridge®/Thin Common Cartridge®, Learning Tools Interoperability®, OneRoster® and Question & Test Interoperability®. Each of these standards includes definition of the data that MUST and MAY be exchanged. In some cases this includes data whose exchange has implications on PII. This document includes a detailed analysis of the data properties, in each of the IMS standards that have such PII implications. Identification of the use of these data properties by an app is an important component of the App Vetting Rubric.

1.1.2 In Scope

The scope of this task force was to enable a standard app vetting process that incorporates the use of the rubric and a method of describing user privacy profiles and tool provider privacy policies. The goal of this process is to enable an open line of communication for suppliers and districts/institutions to work together to provide an accurate review of the organization's products.

The open collaboration between districts/institutions and suppliers also promotes transparency that helps members understand the various components of privacy and terms of service policies and why they are necessary. As a result of this process, users will be able to make informed decisions about the digital resources they use. This app vetting rubric defines a standard set of evaluation questions, grouped by category, with indicators to establish whether an app meets expectations or not.

1.1.3 Out of Scope

The scope of this task force did not include providing guidance or standards for securing data across activities such as transmission and storage of data. This rubric does not enable users to make decisions about how their data is transmitted or stored.

This working group acknowledges the critical importance of all parties to secure data and is supportive of the industry security best practices to ensure private data is secured. While there are numerous legal and regulatory requirements, as well as best practices on the collection, sharing, and safeguarding of Personally Identifiable Information (PII), this task force did not provide conformance of any kind for these standards.

1.2 Structure of this Document

The structure of the rest of this document is:

2. USE-CASES The use-cases that are address by this App Vetting Rubric.
3. APP VETTING RUBRIC Description of a rubric including the definition of the evaluation criteria and how the rubric MAY be extended.
4. APP VETTING PROCESS Description of the process that must be undertaken to complete, revise and maintain an app vetting rubric.
APPENDIX A – DETAILS FOR THE RUBRIC The details for a rubric including the definition of the questions that must be answered to determine the degree to which the evaluation criteria are achieved.
APPENDIX B – INTEROPERABILITY DATA PROPERTIES Identification of the set of data attributes, for each of the IMS specifications that MAY be adopted by an app, which contain PII and PII-related information. The details in this appendix will be expanded in later versions of this document.
APPENDIX C – REVISION HISTORY History of the various published versions of this document. This includes details of the changes made with respect to the previously published version.
APPENDIX D – REFERENCES The details of the set of documents cited within this document.
APPENDIX E – LIST OF CONTRIBUTORS The people who were responsible for the creation of this document.

1.3 Acronyms

ADA
Americans with Disabilities Act
ADV
Advertising
AGS
Assignment & Grade Service
CASE
Competencies & Academic Stabdards Exchange
CC
Common Cartridge
CLR
Comprehensive Learner Record
COPPA
Children's Online Privacy Protection Act
CSV
Comma Serparated Variables
DC
Data Collected
FERPA
Family Educational Rights and Privacy Act
GDPR
General Data Protection Regulation
HECVAT
Higher Education Community Vendor Toolkit
HIPPA
Health Insurance Portability and Accountability Act
HTTP
HyperText Transfer Protocol
JSON
Java Script Object Notation
LMS
Learning Management System
LTI
Learning Tools Interoperability
NRP
Names & Roles Provisioning
PII
Personally Identifiable Information
SEC
Security
SHR
Third-Party Data Sharing
SSL
Secure Socket Layer
SSO
Single Sign On
TCC
Thin Common Cartridge
TLS
Transport Layer Security

1.4 Terminology

2-step authentication
Authentication process that requires 2 steps (such as a password and a key) for user access to the application.
3rd party/parties
Individuals or organizations that are neither users nor the supplier of the application.
Ad targeting
Use of user data, both profile and activity, to generate specific ads targeted at that user.
Cookies
An HTTP cookie (also called web cookie, Internet cookie, browser cookie, or simply cookie) is a small piece of data sent from a website and stored on the user's computer by the user's web browser while the user is browsing.
Data deletion
Remove all data related to a given user.
De-identify
Remove or obfuscate all data related to a given user to the extent that the user can no longer be identified by the data in aggregate.
LTI launch
Initiation of an application launch by a user clicking on a link in the LMS.
Retention
Storage of user data within the systems of the supplier or others.
Social media account
User account on Facebook, Twitter, or other social media platform - especially as used to log into a site not connected to that social media platform via an API.
SSL/TLS Encryption
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are the standard security technologies for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private. Use of SSL is deprecated and apps SHOULD use TLS 1.2 or later versions.
Single Sign On (SSO)
Single Sign On enabled at many institutions and allowing users to connect to the application under review via the same login information they would use for other institution gateways.
Supplier / app supplier
Creator and/or distributor of the application under review.
Unlimited license
All rights to user data (profile, activity, etc.) are granted without condition to the party in question.
User base
All users on a system
Vulnerabilities
Weaknesses in security (identified or not) that place user data at risk in either storage or transit.
Web beacons
An often-transparent graphic image, usually no larger than 1 pixel x 1 pixel, that is placed on a website or in an email that is used to monitor the behavior of the user visiting the Web site or sending the email. It is often used in combination with cookies.

2. Use-cases

Most schools, districts, and institutions struggle to ensure that their teachers and students are using approved digital resources in the classroom and online. A number of schools and institutions have put in place a process for faculty or teachers to make a request for approval of a digital resource. The subsequent evaluation processes are often too long and inefficient to accommodate the “on demand” needs of faculty or teachers, in time for their upcoming classes. The IMS Global App Vetting Rubric can supplement these evaluation processes by allowing faculty and teachers to get a quick snapshot view of an app's data privacy, providing confidence that the chosen app meets the basic requirements for data privacy and security. This allows the teacher to use an app "on demand" while additional evaluation processes are utilized if needed. Evaluation authorities themselves can use the rubric to identify the apps that are safe for on demand use. This also reduces demands on IT and procurement, allowing staff to focus attention on the most promising applications that have the desired privacy profile.

This App Vetting Rubric also benefits Ed-tech suppliers by helping them avoid countless requests from multiple schools, districts, and institutions for the kind of information that the rubric is meant to address. Without this rubric, suppliers have to commit scarce resources to answer questionnaires that address issues very similar to those raised by others. This process promises to ease the supplier's burden of communication allowing them to focus their resources on improving their software and services.

3. App Vetting Rubric

3.1 Key Concepts & Elements

The proliferation of 3rd party learning tools available for use within learning environments is causing an increasing burden for administrators at educational institutions today. Each institution and school district has a responsibility to ensure that the apps they allow teachers to embed within their courses have privacy and security policies that meet institutional requirements when it comes to handling student data. This process of reviewing 3rd party apps to ensure they meet requirements is referred to as App Vetting.

3.1.1 What is a Rubric and How is it Being Used Here?

A Rubric is a scoring guide used to evaluate performance, a product, or a project. Typically, it has three parts: 1) performance criteria, 2) rating scale, and 3) indicators.

Figure 1 Source:https://facultyinnovate.utexas.edu/sites/default/files/build-rubric.pdf

This App Vetting specification defines a Rubric that institutions and school districts can use for App Vetting. Members of the IMS Global community pooled their collective evaluation criteria into a common rubric for reviewing 3rd party apps (members also looked at criteria set by other organizations that vet applications for their data privacy practices). These collective criteria cover a basic set of questions that districts and institutions need to ask when vetting an app.

With a common set of evaluation criteria, each institution or school district can specify their requirements in a consistent way, thereby making it easier for them to vet multiple apps. In addition, when responding to requirements coming from each of their educational customers, suppliers will also have a consistent way to document the behavior of their own apps in each of the required areas.

3.2 Details of the Rubric

While the rubric is a starting point for reviewing the privacy practices of a digital resource or application, the IMS Global process also includes communicating and collaborating with the suppliers to provide feedback and to clarify the supplier’s policies. This open line of communication allows suppliers and districts/institutions to work together to provide an accurate review of the organization's products. The open collaboration between districts/institutions and suppliers also promotes transparency that helps members understand the various components of privacy and terms of service policies and why they are necessary.

The detailed structure and contents of the Rubric are descibed in Appendix A.

3.2.1 How is this Rubric Different from Other Vetting Instruments such as HECVAT?

A The Higher Education Community Vendor Toolkit (HECVAT) [HECVAT] is used within the Higher Education community to assess suppliers of cloud infrastructure services. The most recent version of the HECVAT available when writing this document (v2.1) covers many aspects of supplier-provided services such as company history, business continuity plan, change management process, physical security, firewalls, and networking. These aspects are important to establish a basis for supplier relationships, contracts with institutional specific procurement requirements, and so on. However, when incorporating 3rd party tools into a learning environment, the need is slightly different. Because these 3rd party tools play a supporting role in the overall learning environment, teachers and students often treat them as an extension of a learning environment. This means questions about data collection, ownership, retention, as well as sharing, advertising, and the use of cookies will be more prominent in the App Vetting Rubric.

The App Vetting Rubric also serves as a useful tool for organizations looking for ways to comply with GDPR requirements. GDPR Article 35 describes the need for a Data Protection Impact Assessment; Item 3 therein further qualifies that such assessments are needed when there are automated ways that people will be evaluated, which is often the case with educational apps. The article expands on the provisions of the data protection impact assessment, stating that it should contain a description of the processing operation, the purpose, and what measures exist to safeguard the protection of personal data. The App Vetting Rubric intends to establish a consistent baseline for assessing apps related to privacy and security.

Note: The IMS App Vetting rubric does not address all privacy and security concerns that districts/institutions will have. The light rubric is meant to establish a baseline of criteria and questions that should be asked when reviewing a digital resource. IMS Global is working on an extended version of the rubric that includes an additional seven categories to consider when vetting a digital resource (see the Sub-section on Rubric Extensions).

3.3 Criteria

Those who review potential apps for use at institutions should understand how difficult it is for an app supplier to include all of the requirements of this rubric or the specific criteria important to the institution in question. It is, therefore, crucial to not only review the privacy policy and terms of service agreement but also attempt to reach out to the app supplier and communicate any questions and/or concerns about what may or may not have been found in those policies. Reviewers should take a “If you see something, say something” approach. By communicating with the supplier, reviewers will obtain a more thorough and accurate review of the app while helping to improve their own data privacy practices and transparency, helping countless others. The Rubric contains these four core sections that are essential to do a base level review of a digital resource:

  • Data Collected - covers data the supplier collects as the user interacts with the app. This data could include information provided by the user explicitly as well as information collected by the app during its use. This area concerns who owns the data, what right the user has to have their data deleted, and how long an app supplier may retain the data;
  • Security - covers all of the supplier's back-end security policies and practices. Specifically, it addresses data protection practices, handling of confidential and sensitive information, authentication, and use of cookies;
  • Third-Party Data Sharing - covers all 3rd party interactions with the supplier and with the user’s data. This section also addresses the sharing of user data with 3rd parties;
  • Advertising - covers how the supplier manages advertisements and whether or not there is advertisement targeting or tracking.

3.4 Extensions

The 'light' rubric covers four core basic areas of app vetting. We realize that there are more than four areas where districts and institutions focus when reviewing a digital resource. The following rubric extensions allow an organization to customize their app vetting process to include areas of data privacy and security that are of high importance to the organization:

  • Availability of Policy - wWhether a link to the policy exists, where the link is located, when it is presented to the user and how it is formatted;
  • Data Handling - how suppliers handle data retention and deletion;
  • Social Interactions - how social media is managed and used within the app;
  • Legal - all state and federal regulations on student data including COPPA, FERPA, and HIPPA;
  • Accessibility - accessibility and ADA standards compliance;
  • Mobile - mobile application privacy, safety & security;
  • Integrations - the privacy, safety, and security of 3rd party integrations.

4. App Vetting Process

The process begins with a reviewer surveying a suppliers’ Privacy Policy to identify data collection and sharing policies as it pertains to a specific App. The stated Privacy Policy is then compared with the expectations as established in the App Vetting Rubric. Specifically, the rubric includes what information a user is required to input, data collected during the use of the app, and how the user can interact with their own data. This is the most crucial area when reviewing an application; it determines how a user should interact with the application, or, indeed, whether or not to do so, for the user population that might be candidates for using the app.

Next, it’s important to know how collected data is secured. The app supplier needs to show the steps that they take to secure user data after collecting it. Specifically, they should show how they protect the data and what steps they take to educate users to take part in the users’ own data security awareness.

The important third section of the rubric covers 3rd party interactions, including how the app supplier interacts with 3rd parties and what data it shares with 3rd parties.

The final section of the rubric includes all of the aspects of advertising. This is important as most districts and institutions do not approve of any advertisements directed towards their students. It’s essential to know what advertisements a supplier’s app displays, if any, and how it does so.

4.1 Goals

The App Vetting review and publishing process helps institutions and suppliers understand and address privacy concerns in a cooperative manner with the following conditions:

  • Apps will be reviewed before posting by IMS Global Staff. This step gives the supplier a chance to respond to reviews before they are posted publicly;
  • IMS Global will not post a “Does Not Meet Expectations” review without first contacting the supplier;
  • Suppliers may request re-vetting of their apps when changes have been made to their policies.

This process differs from other existing app vetting approaches because it promotes open communication about supplier products within the IMS Global trusted membership community. This open line of communication allows suppliers and districts/institutions to work together to provide an accurate review of the organization's products.

In addition, the open collaboration between districts/institutions and suppliers promotes transparency that helps all IMS Global members understand the various components of privacy and terms of service policies and why they are necessary.

4.2 Who Can Submit Reviews

Any IMS Member (suppliers/institutions/districts) may submit a review for any IMS Member’s product whether or not they are using the product. Once posted, all vetted app reviews can be viewed by other IMS Global Members and Staff. The app vetting report itself will be viewable under the product’s entry in the IMS Product Directory.

4.3 Governance & Recourse

  • Supplier reviews are given 20 days to meet with IMS after the review has been completed. After 20 days, the review will be posted;
  • IMS receives a notification for every review submitted;
  • All reviews are initially unpublished until IMS confirms that the review meets standards set for a complete and thorough review;
  • Suppliers may submit their own reviews of their products;
  • IMS will work with the reviewer and the supplier if there is a disagreement about the review;
  • If a supplier’s product or privacy policy has changed significantly, it may not match an existing review which had been previously submitted. In that case, suppliers may submit a note for IMS to attach to an existing review. Suppliers may also ask for their now outdated reviews to be removed and revetted.

4.4 Review Submission

  • All reviews indicate whether or not the reviewer spoke with the supplier prior to making the assessment;
  • The Reviewer is required to state how much knowledge they have of the product when conducting the review;
  • All previously posted reviews can be updated;
  • Reviews may allow the reader to see who the reviewer is and how credible they may be;
  • The reviewer is required to indicate if they are using the product or not.

4.5 Notification & Versioning

  • The latest rubric version will be posted on the IMS website https://www.imsglobal.org/activity/app-vetting/rubric-light
  • For clarity in product reviews, rubric versions should be kept consistent for a year. IMS will send an email to the members with major changes to the rubric. Minor changes, such as corrections for typos, usually don’t need notification;
  • Changes to the rubric will not affect existing ratings in the product directory - because each review lists the version of the rubric which was used;
  • When a new rubric version is released, it should be used for any new reviews for the upcoming year;
  • The following process will be used for making updates to the rubric:-
    • The App Vetting group will review changes on an annual basis for major changes
    • Minor changes, such as corrections for typos, could be requested and updated directly by IMS during the year
    • Changes to the rubric will need to go through an approval process to draft and approve a new spec document, according to IMS Technical Board Policies and Procedures.

A. Details for the Rubric

The following table shows each question with specific language which should be used as the evaluation criteria for vetting apps. The rubric includes a key to address specific questions when communicating with IMS as follows:

  • Data Collected (DC)
    • DCQ1-DCQ5 represents the 5 questions under the Data Collected category.
  • Security (SEC)
    • SECQ1-Q5 represents the 5 questions under the Security category.
  • Third Party Data Sharing (SHR)
    • SHRQ1-Q5 represents the 5 questions under the Third Party Data Sharing category.
  • Advertising (ADV)
    • ADVQ1-Q5 represents the 5 questions under the Advertising category.
  • (A)(B)(C) Indicates which expectation an item falls under.
    • (A) Does Not Meet Expectations
    • (B) Meets Expectations (Reservations)
    • (C) Meets Expectations

As an example. Cross referencing DCQ1(c) would point to the 1st question in the data collected category, specifically addressing the “Meets Expectations” column.

Data Collected (DC) Does Not Meet Expectations (A) Meets Expectations (Reservations) (B) Meets Expectations (C)
DCQ1: The policies list all data collected
  • Policies do not list data collected
  • Policies list data collected not crucial to app functionality
  • Policies give a broad statement of data collected
  • Policies are not clear on data collected crucial to app functionality
  • Policies list the data collected
  • Policies state no data collected
DCQ2: The policies indicate how data is collected
  • Policies do not state how data is collected
  • Policies state how data is collected in an unacceptable manner
  • Policies give a broad statement of how data is collected
  • Policies are not clear on how data is collected
  • Policies state specifically how data is collected
  • Policies state no data collected
DCQ3: The policies state who owns the data
  • Policies do not state who owns the data
  • Policies state app supplier owns all data
  • Policies state the user owns the data but grants itself an unlimited license on the use of the data
  • Policies are not clear on who owns what data
  • Policies state the user owns the data alone
  • Policies state no data collected
DCQ4: The policies allow users to delete their data entirely
  • Policies do not state if users can delete their data
  • Policies do not allow data deletion
  • Policies do not state how to delete data
  • Policies state it de-identifies users & cannot fully delete user data
  • Policies are unclear what data can and cannot be deleted
  • Policies allow users to delete data entirely after a period of time
  • Policies state no data collected
DCQ5: The policies state the retention of data
  • Policies do not state its data retention policy
  • Policies state that data is retained for as long as supplier needs it
  • Policies state a 90-day retention policy
  • Policies give a general statement of data retention with no time period specified
  • Policies have a 60-day or less retention policy
  • Policies state no data collected
Security (SEC) Does Not Meet Expectations (A) Meets Expectations (Reservations) (B) Meets Expectations (C)
SECQ1: Policies state how data is protected
  • Policies do not indicate how data is protected
  • Policies state the protection of data in an unacceptable manner
  • Policies give a broad statement on steps taken to protect data
  • Policies are unclear on how data is protected
  • Policies list the steps taken to protect data
  • Policies state no data collected
SECQ2: Policies state all confidential & sensitive information is encrypted throughout
  • Policies do not mention data encryption
  • App Supplier does not pass encryption tests
  • Policies give a broad statement on SSL/TLS encryption
  • App Supplier encrypts data at login only
  • Encryption tests show minor vulnerabilities
  • Data encrypted throughout (including the use of TLS 1.2, or later)
  • Passes an encryption test with no vulnerabilities
  • Policies state no data collected
SECQ3: Policies state whether or not it enforces strong password creation
  • Policies do not mention password creation requirements
  • Policies allow very simple password creation
  • App supplier has social media account creation option
  • Policies provide guidance for password creation
  • Policies urge strong password creation but does not enforce it
  • Supplier enforces strong password creation
  • Supplier user base exempt from password requirements
  • No account creation required
SECQ4: Policies indicate whether or not it has 2-step authentication
  • Supplier does not have 2-step authentication
  • Supplier authenticates with social media or web account
  • Supplier uses a weak form of authentication
  • Policies state the use of 2-step authentication but do not enforce it at login
  • Supplier uses SSO or an LTI launch
  • No account creation required
  • Supplier user base exempt from 2-step authentication requirements
SECQ5: Policies state the use of cookies
  • Policies do not mention the use of cookies
  • Policies state the use of cookies for purposes not related to app functionality
  • Policies give a broad statement on the use of cookies
  • Policies are unclear if cookies are crucial for app functionality
  • Policies list all cookies used and each cookie's purpose
  • Policy state that it only uses cookies that are crucial for app functionality
Third Party Data Sharing (SHR) Does Not Meet Expectations (A) Meets Expectations (Reservations) (B) Meets Expectations (C)
SHRQ1:The policies state the use of third parties
  • Policies do not mention the use of third parties
  • Policies state the use of third parties not critical to app functionality
  • Policies give a broad generalization on use of third parties
  • Policies are unclear on the use of third parties strictly for app functionality only
  • Policies list each third party separately
  • Policies state third party use strictly for app functionality
  • Policies state that they do not use third parties
SHRQ2: The policies state what information is shared with each third party
  • Policies do not indicate what data is shared with third parties
  • Supplier shares data with third parties not critical to app functionality
  • Policies group all third parties with same data shared
  • Policies are not clear on what data is shared with each third party
  • Policies are unclear if data shared with each third party are crucial to app functionality
  • Policies list the data it shares with each third party separately
  • Policies state that it does not share any data with any third party
SHRQ3: Users can opt out of third party data sharing
  • Policies do not state if users can opt out of third party data sharing
  • Policies does not allow users to opt out
  • Policies state users can opt out but the process is not simple or quick
  • Policies are unclear as to what exactly users can opt out of
  • Policies include an easy opt out process for users
  • Policies state that it does not share any data with any third party
SHRQ4: Supplier requires their third parties to adhere to the terms of the vendor/customer agreement
  • Policies do not mention if third parties held to same terms
  • Supplier claims no responsibility for third party policies
  • Supplier does not claim responsibility for third party links but warns users against sharing additional data
  • Policies state "at your own risk" when interacting with a third party links
  • Supplier claims responsibility for third party privacy practices
  • Policies state that it does not share any data with any third party
SHRQ5: User is notified of a change in third parties
  • User is not notified when there are new data sharing terms with third party
  • Supplier changes third parties & does not hold third party to same terms
  • Supplier changes third party with no mention of terms
  • Policies are unclear on data sharing terms with the new third parties
  • Supplier changes third party and keeps the same data sharing terms
  • Supplier does not use any third parties
Advertising (ADV) Does Not Meet Expectations (A) Meets Expectations (Reservations) (B) Meets Expectations (C)
ADVQ1: Policies indicate whether or not advertisements are displayed
  • No indication if ads are displayed
  • Unacceptable ads are displayed
  • Supplier claims no responsibility for ads
  • Ads are displayed before login only
  • Platform-based ads are displayed only
  • No ads are displayed
ADVQ2: Policies indicate whether or not users are targeted for advertisement
  • Policies state that it serves interest-based ads to its users
  • Policies state that users are targeted for ads
  • Policies state the possible use of ad targeting by third parties
  • Supplier claims no responsibility for ads on its platform
  • Policies guarantee no ad targeting
  • Policies state no ads are used on its platform
ADVQ3: Policies indicate whether or not any third parties track or collect information for advertisement
  • Policies explicitly state third party tracking of users
  • Policies do not mention if third parties can track users for ads
  • Policies state that third parties might track or collect user data but gives you the option to opt out
  • Users can opt out of ad networks but not clear if user can opt out of all ads or tracking across web
  • Policies state third parties are not used for ads or tracking
ADVQ4: Policies indicate whether or not web beacons or other tracking methods are used for ad purposes
  • Policies state use of web beacons or other tracking methods for ads
  • Policies do not mention methods used for tracking users for ads
  • Policies state the use of tracking technologies strictly for purposes intended for app functionality
  • Policies are unclear on what methods are used for tracking users
  • Policies state that it only tracks interactions within its application
  • Policies state that it does not use any tracking technologies for ads
ADVQ5: Policies state whether or not users can opt out of sharing data with advertisers
  • Policies do not mention if users can opt out of sharing data with advertisers
  • Supplier does not have an opt out option for users
  • Policies mention users can opt out but does not make it clear what the user can opt out of
  • Policies make a broad statement for opting out of data sharing with no clear instructions on how to do so
  • Policies state in detail how users can opt out of sharing data with advertisers
  • Policies state no ads are used on its platform

B. Interoperability Data Properties

IMS has several specifications that MAY be used in apps, namely:

These specifications describe the exchange of data between EdTech systems, applications and tools. Each of these specifications contains a number of data models that define the data that MUST and MAY be exchanged. This data includes PII information. The following subsections identify privacy information that it is possible to exchange using each of the IMS specifications.

Later versions of this document will include a detailed analysis of the security/privacy implications when exchanging data using the above set of IMS specifications.

C. Revision History

This section is non-normative.

C.1 Version History

Version No. Release Date Comments
Final Release 1.0 12th July, 2020 The first, formal release of this document. This is released for public adoption.

D. References

D.1 Normative references

[CAL1p1]
Caliper Analytics Specification 1.1 Final Release. IMS Global Learning Consortium, Inc. January 2018. URL: https://www.imsglobal.org/sites/default/files/caliper/v1p1/caliper-spec-v1p1/caliper-spec-v1p1.html
[CAL1p2]
Caliper Analytics Specification 1.2. IMS Global Learning Consortium, Inc. March 2020. URL: https://www.imsglobal.org/spec/caliper-spec/v1p2/
[CASE1p0]
Competencies and Academic Standards Exchange (CASE) Service 1.0 Specification Final Release. IMS Global Learning Consortium, Inc. July 2017. URL: https://www.imsglobal.org/sites/default/files/CASE/casev1p0/information_model/caseservicev1p0_infomodelv1p0.html
[CC1p2]
Common Cartridge 1.2 Final Release. IMS Global Learning Consortium, Inc. October 2011. URL: https://www.imsglobal.org/cc/ccv1p2/imscc_profilev1p2-Overview.html
[CC1p3]
Common Cartridge 1.3 Final Release. IMS Global Learning Consortium, Inc. July 2013. URL: https://www.imsglobal.org/cc/ccv1p3/imscc_Overview-v1p3.html
[CLR1p0]
Comprehensive Learner Record 1.0 Specification. IMS Global Learning Consortium, Inc. May 2020. URL: https://www.imsglobal.org/spec/clr/v1p0/
[LTI1p1]
Learning Tools Interoperability Core 1.1.1 Specification Final Release. IMS Global Learning Consortium, Inc. September 2012. URL: https://www.imsglobal.org/specs/ltiv1p1p1/implementation-guide
[LTI1p3]
Learning Tools Interoperability Core 1.3 Specification Final Release. IMS Global Learning Consortium, Inc. April 2019. URL: https://www.imsglobal.org/spec/lti/v1p3/
[LTIAGS2p0]
Learning Tools Interoperability Assignment and Grade Service 2.0 Specification Final Release. IMS Global Learning Consortium, Inc. April 2019. URL: https://www.imsglobal.org/spec/lti-ags/v2p0/
[LTIDL2p0]
Learning Tools Interoperability Deep Linking 2.0 Specification Final Release. IMS Global Learning Consortium, Inc. April 2019. URL: https://www.imsglobal.org/spec/lti-dl/v2p0/
[LTINRP2p0]
Learning Tools Interoperability Names and Role Provisioning Services 2.0 Final Release. IMS Global Learning Consortium, Inc. April 2019. URL: https://www.imsglobal.org/spec/lti-nrps/v2p0/
[LTIRS1p0]
LTI Resource Search 1.0 Final Release. IMS Global Learning Consortium, Inc. September 2018. URL: https://www.imsglobal.org/spec/lti-rs/v1p0/
[OB2p0]
Open Badges 2.0 Final Release. IMS Global Learning Consortium, Inc. April 2018. URL: https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html
[OB2p1]
Open Badges 2.1 (Badge Connect API). IMS Global Learning Consortium, Inc. March 2020. URL: https://www.imsglobal.org/open-badges-21-badge-connect-api-now-available
[OR1p1]
OneRoster 1.1 Specification Final Release. IMS Global Learning Consortium, Inc. March, 2020. URL: https://www.imsglobal.org/oneroster-v11-final-specification.html
[OR1p1CSV]
OneRoster 1.1 Specification Final Release. IMS Global Learning Consortium, Inc. April, 2017. URL: https://www.imsglobal.org/oneroster-v11-final-csv-tables.html
[OR1p2CSV]
OneRoster 1.2 CSV Binding. IMS Global Learning Consortium, Inc. April, 2020. URL: https://www.imsglobal.org/lis/imsonerosterv1p2/imsOneRosterv1p2-csv-bindingv1p0.html
[OR1p2GBK]
OneRoster 1.2 Gradebook Services. IMS Global Learning Consortium, Inc. April, 2020. URL: https://www.imsglobal.org/lis/imsonerosterv1p2/imsOneRosterv1p2-gradebook-infomodelv1p0.html
[OR1p2RES]
OneRoster 1.2 Resource Services. IMS Global Learning Consortium, Inc. April, 2020. URL: https://www.imsglobal.org/lis/imsonerosterv1p2/imsOneRosterv1p2-resource-infomodelv1p0.html
[OR1p2ROS]
OneRoster 1.2 Rostering Services. IMS Global Learning Consortium, Inc. April, 2020. URL: https://www.imsglobal.org/lis/imsonerosterv1p2/imsOneRosterv1p2-rostering-infomodelv1p0.html
[TCC1p2]
IMS Thin Common Cartridge 1.2 Impelemtatiion Guide File Release. IMS Global Learning Consortium, Inc. May 2015. URL: https://www.imsglobal.org/cc/CCv1p0thin/ims_thinCC_impl-v1p0.html
[TCC1p3]
IMS Thin Common Cartridge 1.2 Impelemtatiion Guide File Release. IMS Global Learning Consortium, Inc. May 2015. URL: https://www.imsglobal.org/cc/CCv1p0thin/ims_thinCC_impl-v1p0.html

D.2 Informative references

[HECVAT]
Educause Higher Education Community Vendor Assessment Toolkit. April 2020. URL: https://library.educause.edu/resources/2016/10/higher-education-community-vendor-assessment-toolkit

E. List of Contributors

The following individuals contributed to the development of this document:

Name Organization Role
Beatriz Arnillas itslearning  
Linda Feng Unicon  
Steve Gance Washington State Board For Community & Technical Colleges  
Viktor Hagg D2L Corporation  
Dale Johnson University Of Wisconsin System  
Kevin Lewis IMS Global editor
Lisa Mattson IMS Global  
Jenna Olsen Western Governors University  
Colin Smythe IMS Global  
Nick Thompson University Of California, Los Angeles  

IMS Global Learning Consortium, Inc. ("IMS Global") is publishing the information contained in this document ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS Global makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

IMS Global would appreciate receiving your comments and suggestions.

Please contact IMS Global through our website at http://www.imsglobal.org.

Please refer to Document Name: IMS Data Privacy 1.0

Date: July 12th, 2020