1EdTech Data Privacy
1EdTech Data Privacy
Version 1.0
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.
© 2020 1EdTech 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, 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 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.
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.
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 |
|
|
|
DCQ2: The policies indicate how data is collected |
|
|
|
DCQ3: The policies state who owns the data |
|
|
|
DCQ4: The policies allow users to delete their data entirely |
|
|
|
DCQ5: The policies state the retention of data |
|
|
|
Security (SEC) | Does Not Meet Expectations (A) | Meets Expectations (Reservations) (B) | Meets Expectations (C) |
SECQ1: Policies state how data is protected |
|
|
|
SECQ2: Policies state all confidential & sensitive information is encrypted throughout |
|
|
|
SECQ3: Policies state whether or not it enforces strong password creation |
|
|
|
SECQ4: Policies indicate whether or not it has 2-step authentication |
|
|
|
SECQ5: Policies state the use of cookies |
|
|
|
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 |
|
|
|
SHRQ2: The policies state what information is shared with each third party |
|
|
|
SHRQ3: Users can opt out of third party data sharing |
|
|
|
SHRQ4: Supplier requires their third parties to adhere to the terms of the vendor/customer agreement |
|
|
|
SHRQ5: User is notified of a change in 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 |
|
|
|
ADVQ2: Policies indicate whether or not users are targeted for advertisement |
|
|
|
ADVQ3: Policies indicate whether or not any third parties track or collect information for advertisement |
|
|
|
ADVQ4: Policies indicate whether or not web beacons or other tracking methods are used for ad purposes |
|
|
|
ADVQ5: Policies state whether or not users can opt out of sharing data with advertisers |
|
|
|
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
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 |