1EdTech Data Privacy

1EdTech Final Release
Version 1.0

1EdTech 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.

1EdTech 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 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech 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 1EdTech found on the 1EdTech 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 1EdTech 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.

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, 1EdTech 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 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.

1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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. 1EdTech 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 - whether 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 1EdTech Staff. This step gives the supplier a chance to respond to reviews before they are posted publicly;
1EdTech 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 1EdTech 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 1EdTech members understand the various components of privacy and terms of service policies and why they are necessary.

4.2 Who Can Submit Reviews

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

4.3 Governance & Recourse

Supplier reviews are given 20 days to meet with 1EdTech after the review has been completed. After 20 days, the review will be posted;
1EdTech receives a notification for every review submitted;
All reviews are initially unpublished until 1EdTech confirms that the review meets standards set for a complete and thorough review;
Suppliers may submit their own reviews of their products;
1EdTech 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 1EdTech 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 1EdTech website https://www.imsglobal.org/activity/app-vetting/rubric-light
For clarity in product reviews, rubric versions should be kept consistent for a year. 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 Policies state that the app only uses cookies that are crucial for 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

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

1EdTech OneRoster 1.1 [OR1p1], [OR1p1CSV]
1EdTech OneRoster 1.2 [OR1p2ROS], [OR1p2RES], [OR1p2GBK], [OR1p2CSV]
1EdTech Learning Tools Interoperability (LTI) 1.1 [LTI1p1]
1EdTech Learning Tools Interoperability (LTI) 1.3 [LTI1p3]
1EdTech LTI Advantage Extensions [LTIDL2p0], [LTINRP2p0], [LTIAGS2p0]
1EdTech LTI Names & Roles Provisioning Service (NRP) [LTINRP2p0]
1EdTech LTI Assignment & Grade Service (AGS) [LTIAGS2p0]
1EdTech Competencies & Academic Standards Exchange (CASE) [CASE1p0]
1EdTech Learning Tools Interoperability Resource Search [LTIRS1p0]
1EdTech Comprehensive Learner Record (CLR) [CLR1p0]
1EdTech Open Badge 2.0 [OB2p0]
1EdTech Open Badge 2.1 [OB2p1]
1EdTech Caliper 1.1 [CAL1p1]
1EdTech Caliper 1.2 [CAL1p2]
1EdTech Common Cartridge 1.2 [CC1p2] & 1EdTech Thin Common Cartridge 1.2 [TCC1p2]
1EdTech Common Cartridge 1.3 [CC1p3] & 1EdTech Thin Common Cartridge 1.3 [TCC1p3]

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 1EdTech specifications.

Later versions of this document will include a detailed analysis of the security/privacy implications when exchanging data using the above set of 1EdTech 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.
	18 September 2020	Corrects some minor spelling and other text errors.

D. References

D.1 Normative references

[CAL1p1]: Caliper Analytics Specification 1.1 Final Release. 1EdTech 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. 1EdTech 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. 1EdTech 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. 1EdTech Consortium, Inc. October 2011. URL: https://www.imsglobal.org/cc/ccv1p2/imscc_profilev1p2-Overview.html
[CC1p3]: Common Cartridge 1.3 Final Release. 1EdTech Consortium, Inc. July 2013. URL: https://www.imsglobal.org/cc/ccv1p3/imscc_Overview-v1p3.html
[CLR1p0]: Comprehensive Learner Record 1.0 Specification. 1EdTech Consortium, Inc. May 2020. URL: https://www.imsglobal.org/spec/clr/v1p0/
[LTI1p1]: Learning Tools Interoperability Core 1.1.1 Specification Final Release. 1EdTech Consortium, Inc. September 2012. URL: https://www.imsglobal.org/specs/ltiv1p1p1/implementation-guide
[LTI1p3]: Learning Tools Interoperability Core 1.3 Specification Final Release. 1EdTech 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. 1EdTech Consortium, Inc. April 2019. URL: https://www.imsglobal.org/spec/lti-ags/v2p0/
[LTIDL2p0]: Learning Tools Interoperability Deep Linking 2.0 Specification Final Release. 1EdTech 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. 1EdTech Consortium, Inc. April 2019. URL: https://www.imsglobal.org/spec/lti-nrps/v2p0/
[LTIRS1p0]: LTI Resource Search 1.0 Final Release. 1EdTech Consortium, Inc. September 2018. URL: https://www.imsglobal.org/spec/lti-rs/v1p0/
[OB2p0]: Open Badges 2.0 Final Release. 1EdTech Consortium, Inc. April 2018. URL: https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html
[OB2p1]: Open Badges 2.1 (Badge Connect API). 1EdTech Consortium, Inc. March 2020. URL: https://www.imsglobal.org/open-badges-21-badge-connect-api-now-available
[OR1p1]: OneRoster 1.1 Specification Final Release. 1EdTech Consortium, Inc. March, 2020. URL: https://www.imsglobal.org/oneroster-v11-final-specification.html
[OR1p1CSV]: OneRoster 1.1 Specification Final Release. 1EdTech Consortium, Inc. April, 2017. URL: https://www.imsglobal.org/oneroster-v11-final-csv-tables.html
[OR1p2CSV]: OneRoster 1.2 CSV Binding. 1EdTech Consortium, Inc. April, 2020. URL: https://www.imsglobal.org/lis/imsonerosterv1p2/imsOneRosterv1p2-csv-bindingv1p0.html
[OR1p2GBK]: OneRoster 1.2 Gradebook Services. 1EdTech Consortium, Inc. April, 2020. URL: https://www.imsglobal.org/lis/imsonerosterv1p2/imsOneRosterv1p2-gradebook-infomodelv1p0.html
[OR1p2RES]: OneRoster 1.2 Resource Services. 1EdTech Consortium, Inc. April, 2020. URL: https://www.imsglobal.org/lis/imsonerosterv1p2/imsOneRosterv1p2-resource-infomodelv1p0.html
[OR1p2ROS]: OneRoster 1.2 Rostering Services. 1EdTech Consortium, Inc. April, 2020. URL: https://www.imsglobal.org/lis/imsonerosterv1p2/imsOneRosterv1p2-rostering-infomodelv1p0.html
[TCC1p2]: 1EdTech Thin Common Cartridge 1.2 Impelemtatiion Guide File Release. 1EdTech Consortium, Inc. May 2015. URL: https://www.imsglobal.org/cc/CCv1p0thin/ims_thinCC_impl-v1p0.html
[TCC1p3]: 1EdTech Thin Common Cartridge 1.2 Impelemtatiion Guide File Release. 1EdTech 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	1EdTech	editor
Lisa Mattson	1EdTech
Jenna Olsen	Western Governors University
Colin Smythe	1EdTech
Nick Thompson	University Of California, Los Angeles

Specification Images:

You are here