Unique ID Management Best Practices

Unique ID Management Guide Best Practices

for IMS Members


This document addresses some of the challenges presented by teaching and learning ecosystems and the use of Unique IDs. Adhering to standard best practices for Unique IDs benefits many audiences within the teaching and learning sphere, including learners whose experience with technology can be made more seamless if Unique ID best practices are followed. This document addresses those best practices within the scope of recommendations for academic institutions and suppliers serving that audience, as well as recommendations for IMS Global Learning Consortium. In this context, a Unique ID is an unshared ID that can relate to one and only one object: a person, course/class, or resource.

The information in this document was authored by IMS members of a Unique ID volunteer task force (2018-2019).

This document is intended for IMS members. Anticipated subsequent work includes revisions of this document, a separate version for non-members, and IMS development of multiple standardized data models.

IMS Members Edition
Version 1
May 2020



A modern institution’s teaching and learning ecosystem is comprised of multiple software products that need to operate as a cohesive whole for the benefit of learners, teachers, and administrators. The ability to determine and relate the identity and context of a user while they navigate the educational technology ecosystem is often an issue as product suppliers and institutions may utilize different data points and methodologies. To improve the consistency and quality of data available for institutions and learners, it is necessary to improve practices and guidance in IMS specifications and improve supplier and institutional adherence to best practices for managing unique identifiers.

To understand the problem, an IMS task force was assembled to analyze the current challenges faced by suppliers and institutions in regard to learning analytics. The Unique ID Management task force discovered the inconsistency of identifiers led to issues where an institution was unable to leverage Caliper Analytics events passed back from a supplier because they did not use or reference back to the user nor context identifiers originally passed on by the institution.

To resolve this issue, institutions and suppliers must collaborate to ensure they are using identifiers that are known and can be related back to the user and context. Additionally, care must be taken in future specification development to ensure consistent handling of unique ids across the IMS portfolio.

This guide governs the handling of unique identifiers for Persons, Courses, and Resources. The original creation of those identifiers will not be covered in this document.


Problem Statement

Data identifying a user within institutional and supplier platforms may not be consistent throughout institutions’ application systems (“the ecosystem”) and often requires resolution processes or translation to use the data; or worse, the data may not be usable at all. This is especially true in support of teaching and learning analytics. As IMS specifications have evolved with broader adoption, there exists a need for better practices to ensure consistency in how users and context are defined between multiple systems. In this document, the objective is to describe the behavior of organizations and systems using IMS specifications in order to arrive at the desired consistency in processing user and related data. 

An important notion here is a unique master identifier for a user; that and other terms are defined later in this document. A key principle to this guide is that a unique ID is one that can relate to one and only one object: a person, course/class, or resource. An object may never share the unique ID assigned to another object.

Goals of the Unique ID Management Task Force

  • Establish best practices to effectively manage identity throughout IMS specifications in the ecosystem so that consuming systems can resolve data events to unique identifiers. The identifiers in consideration are related primarily to Person, but also may include unique Course/Section context identifiers and unique course material Resource identifiers. 
  • Identify opportunities for improving alignment between IMS specifications on the use of identifiers for users and context to make it easier for institutions, districts, and suppliers to leverage the full power of interoperability.

Goals of This Guide

  • Provide guidance on how to consider unique identifiers when developing educational ecosystems and integrating with third parties.
  • Document recommended changes to IMS specifications and/or implementation and certification practices to improve support for unique identifiers across educational ecosystems.

Out of Scope

For the purpose of this guide, the task force considers the following out of scope:

  • Topics related to a universal person identifier, which would be applicable beyond an institution’s application systems. Such a universal identifier, when and if it is available, will be supportable by future IMS specifications. 
  • The origin of identifiers (Persons, Courses, and Resources).
  • How to define unique identifiers for institutions, product suppliers, or applications. 
  • Arguments for or against the formation of governmental or consortia identity issuers. This document is concerned with the desired behavior of organizations and systems working with existing user data regardless of origin.
  • Instructions for providers.

It is assumed, therefore, in this paper, that the unique identifiers have been assigned within the institution’s or organization’s ecosystem. The role of this guidance is to ensure the consistent handling of those already-defined identifiers. 

Subsequent versions of this guide could address ResourceID uniqueness and workflow application.

Existing IMS Support for Identifiers

  • sourcedId Attribute - The sourcedId is the interoperability identifier used to uniquely identify a Person, Class or Resource within the construct of IMS specifications. It may or may not carry any significance outside of the scope of an IMS integration.
  • userMasterIdentifier Attribute - OneRoster 1.2 introduces a new field, userMasterIdentifier. This is intended to ensure that all of the system identifiers/accounts etc., can be reconciled to the same user.


User Stories

The task force used the following summary user stories to guide their work:

  • As a teacher I want to bring together results from multiple activities, all aligned to the same competency, many/all delivered via multiple systems, in one place in order to make proficiency mastery decisions. 
  • As a curriculum director, I want to evaluate the impact of student activities across multiple systems on student outcomes so that I can identify effective sequences of activities and gauge activity/intervention effectiveness.
  • As an analyst, I want learning events for a specific user to be easily aggregated across all of our organizations’ data systems via a consistent unique user identifier.
  • As an administrator, I want to ensure that all of my suppliers are passing back data with the user and context identified correctly so I can use the data for efficacy research and remediation technologies.




Institutions, Districts & Schools

Institutions, districts, and schools must take a leading role in setting expectations with their technology, learning, and content partners in defining how they identify their users and course context. Doing so will result in much higher quality information available for the organization and the learner, and benefit teaching and learning.

  1. Institutions, Districts, and Schools should clearly establish and document what user and context identifier(s) they will use when passing users to third party systems.
  2. The following should be considered when selecting what identifier shall be used:
    1. A sufficiently unique and stable identifier
    2. Intended for usage by the tool provider
    3. Durably associated with the student
  3. These identifiers should not in themselves be personally identifiable, e.g. they should be anonymous upon viewing and relatable to the actual person at the source system. Specifically, they should avoid using personal email addresses, phone numbers, social security numbers or other governmentally issued IDs. All applicable laws and district/system guidance should be taken into account when making a decision.
  4. Technical administrators should determine in which system the “source” identifier will be maintained and proactively communicate this to all parties that help manage information systems. For example, in the case of Person, the source system may be an identity management applicator or a student information system. 
  5. Institutions, Districts, and Schools manage the “source of truth” for the identification of users. For technical leaders, this comes with responsibility which includes:
    1. Providing an identifier for their users that adheres to the properties stated above.
    2. Only when necessary providing additional personal information about their users to suppliers with a justifiable claim to this information, in order to ensure the proper functioning of services for the educational institution.
    3. Holding suppliers accountable for ensuring data about their users is properly and consistently associated with their preferred source identifiers.


Suppliers that provide educational software platforms must work closely with their educational customers and partners to ensure fidelity and consistency in the use of unique identifiers passed between their systems.

  1. Suppliers should work with their institutional customers to clearly coordinate the use of identifiers and ensure a one-to-one relationship between institutional unique identifiers and any supplier identifiers in instances where a singular identifier cannot be used.
  2. The identifiers should always be associated with any data the supplier collects on engagement, outcomes, or other activity that occurs within the supplier platform and consistently passed back to any receiving systems. As a core principle, if a system receives a source identifier it must pass it on to the next system and include it in its output event streams used for analytics.

IMS Global Learning Consortium (IMS)

IMS should continue to evolve and support the changing needs of both institutions and suppliers and develop more coordination with identifiers between specifications.

  1. IMS should define a new global identifier schema or service for use by the various specifications for documenting the source or origin of an identifier so that the authority of it can be ascertained by platforms receiving it.
  2. IMS should implement a more formalized mechanism for cross task force coordination specifically to address identifiers.
  3. IMS should provide guidance on standardizing a common model for making a URI out of a string.
  4. IMS should consider defining a standard or service for how an alias or “also known as” identifier should be used within specifications.


Specification-Level Recommendations

Key IMS specifications and Unique ID best practices are outlined. Details are not comprehensive to the IMS catalog nor to data management best practices.  See for the most current updates, particularly the development of a Common Data Model.

Caliper Analytics®

Caliper Analytics enables institutions to collect learning data from digital resources to better understand and visualize learning activity and product usage data, and present this information to students, instructors, and advisors in meaningful ways to help inform:

  • Student recruitment and retention plans
  • Program, curriculum, and course design
  • Student intervention measures 

Caliper Analytics defines a number of metric profiles, each of which models a learning activity or a supporting activity that helps facilitate learning. Each profile provides a domain-specific set of terms and concepts that application designers and developers can draw upon to describe common user interactions in a consistent manner using a shared vocabulary. Annotating a reading, playing a video, taking a test, or grading an assignment submission represent a few examples of the many activities or events that Caliper Analytics's metric profiles attempt to describe.

Caliper Analytics & UNIQUE IDENTIFIERS

The Caliper Analytics 1.1 specification uses “” to identify the user that is the subject of events or actions. properties, when used for agents who are people, should reference users with a consistent unique identifier. Event.object and can reference objects such as courses or classes.


It’s recommended that the Caliper Analytics specification should act to make improvements on the guidance provided in its implementation guides and other documentation that incorporate the following.

  1. Identifiers generated by the event producer (sensor application) should be represented as defined attributes or otherwise listed in the Caliper Analytics event.
  2. Identifiers that were passed into the sensor application (an example would be LTI launch parameters) should be preserved and included as federatedSession properties.
  3. These best practices SHOULD also apply when integrations are configured or negotiated “out of band” and without LTI.
  4. An example payload extension SHOULD be provided that could be applied to any Caliper Analytics 1.1 event.

Learning Tools Interoperability® (LTI®)

The IMS LTI standard prescribes a way to easily and securely connect learning applications and tools with platforms like learning management systems (LMS), portals and learning object repositories, in a secure and standard way without the need for custom programming. Using LTI, if you are using a tool such as an interactive assessment application or virtual chemistry lab, you can securely connect to your LMS with a few clicks. LTI consists of a central core that handles the launch and discrete services to add standard features and functions. The LTI core establishes a secure connection and confirms the tool’s authenticity while the services add features like the exchange of assignment and grade data between an assessment tool and your LMS gradebook.


LTI messages use opaque values as unique identifiers for objects such as users and courses. This can cause issues for tools that have been pre-provisioned with such data as they will likely have different identifiers from those passed in LTI messages. To solve this problem, tools should take advantage of the sourcedId parameters available in LTI messages. These parameters are based on the Learning Information Services (LIS) specification which contains the values used to provision other systems. Tools can use these values to match the objects they have already created.

The LTI specification can use two different fields to identify a single user:

ID Field LTI 1.1 NAME LTI 1.3 NAME
Opaque, consistent ID generated by LMS. This value is always sent. user_id sub
ID generated by SIS using LIS values. This value may not be sent depending on privacy settings in the LMS. lis_person_sourcedid



It is recommended that the LTI specification provides more clarity on the use of sub/user_id and the lis_person_sourcedid as identifying fields to ensure consistency. Additional effort should be made to ensure the following are adhered to within the specification and supporting documentation:

  1. If the LMS has a way to generate a pseudonym (see definition below) or opaque identifier, this pseudonym or identifier MAY be used for the LTI sub/user_id value.
  2. The meaning of the qualifiers "sufficiently unique and stable" and "durable" is dependent on the use case in which the LTI exchange is used. The tool provider MUST be able to depend on the uniqueness, stability, and its association with the student for at least the duration of the service that the tool provider provides.
  3. Any value passed for sub/user_id may be:
    • Sufficiently unique and stable identifier.
    • Provided by the platform.
    • Provided by the institution, district, school, or platform.
  4. If a platform or tool is provided with lis_person_sourcedid for a user then the product or tool should pass that value as received to other tools and platforms that are subsequently integrated. The goal is to pass on the identifiers received about the user with fidelity. 


OneRoster is the standard specification for securely sharing class rosters and related data between a student information system (SIS) and any other system, typically a content application or learning management system (LMS). The OneRoster standard supports direct system exchanges using REST API’s and as well as a spreadsheet-style (CSV) export-import.

OneRoster consists of three services. Working with:

  • Enrollment/membership information within courses and classes [Rostering]
  • Formative and Summative Scores [Gradebook]
  • Resources within courses and classes [Resources]


OneRoster 1.1 specifies several different fields to uniquely identify a user. The sourcedId is the interoperability identifier used to uniquely identify a user within the construct of IMS specifications. It may not carry any significance outside of the scope of an IMS integration. Additionally, OneRoster defines a collection of “userIds”. This is a loose construct that allows for an arbitrary number of identifiers to be attached to the user. Here is where external identifiers can be defined such as active directory ID, LTI id, or some other identifier.

OneRoster 1.2 introduces a new field: userMasterIdentifier. This is intended to be used to ensure that all of the system identifiers/accounts etc. can be reconciled to the same user. This field is additive and OneRoster 1.2 still supports the identifiers listed in the OneRoster 1.1 section.

The OneRoster Implementation Guide states: "...the associated 'sourcedId' MUST NOT be reassigned to another object. Therefore, once a 'sourcedId' has been assigned it is permanently allocated to the associated object and so can be used to recover 'deleted' data.


It’s recommended that OneRoster consider the following:

  1. Evaluate opportunities where possible to improve terminology consistency with other IMS specifications such as userMasterIdentifier and a standardized identifier vocabulary.
  2. Leverage best practices outlined in this document for future development on specifications to ensure alignment.

Question and Test Interoperability® (QTI®)

The IMS QTI specification enables the exchange of item and test content and results data between authoring tools, item banks, test construction tools, learning platforms, assessment delivery systems, and scoring/analytics engines.


As an assessment item standard, there is generally no use of provided unique identifiers for actor and context. However, there are some exceptional circumstances where they may be leveraged in the future.


The QTI project group also has organized a task force to define a standard for computer adaptive testing (CAT). The CAT specification defines a way of connecting external adaptive engines to test delivery platforms to provide assessments that adapt to the responses of the test candidate during the exam. This work should leverage best practices outlined in this document for future development to ensure alignment including the use of common terminologies.

Comprehensive Learner Record

The IMS Comprehensive Learner Record (CLR) specification has been designed to create, transmit, and render an individual's set of achievements, as issued by multiple learning providers, in a machine-readable format that can be curated into verifiable digital records of achievement.


The learner is the subject of the CLR, thus the learner must be uniquely identified within any CLR system. A learner is described by the Learner Profile object that contains a number of identity-related properties, including SourcedId as found in other IMS standards. It is recommended that institutions use Profile.sourcedId as the unique identifier of the learner. It might be tempting to use other existing properties such as Profile.studentId or as a unique identifier, however, by definition across multiple IMS standards, Profile.sourcedId should hold the institution’s unique student identifier.

Open Badges

Open Badges are visual symbols of accomplishments packed with verifiable metadata according to the Open Badges specification. The Open Badges specification defines the properties necessary to define an achievement and award it to a recipient, as well as procedures for verifying badge authenticity and “baking” badge information into portable image files.


Open Badges are issued to recipients who are described by the Recipient Profile. The Profile object in OB 2.0 allows a recipient to be identified by an email address, a phone number, or a web address. By far, the most common identifier currently used for a recipient is an email address. Institutions should consider whether they manage email addresses as unique identifiers for students. Today, it is recommended that institutions issue badges to students using the student’s email address as the unique recipient identifier.

SourcedId is not directly supported in Open Badges 2.0. However, OB 2.0 allows additional properties to be included within a badge assertion, particularly for internal system usage. It is conceivable that a badge issuing platform may add a feature to support SourcedId as an additional property to be used in conjunction with the recipient’s email address. Because the SourcedId will not have meaning outside of the institution’s systems, and one of the email/phone/URL is used in the badge verification process, SourcedId should not be used as the sole identifier of a recipient of an Open Badge.

Future Plans


The expectation of the Unique ID task force as outlined in the group’s call for participation is that the recommendations contained here will be presented and reviewed by the relevant product steering committees and project groups leadership for consideration of action. Action is expected to be in the form of changes to the future versions of the specifications and/or the certification requirement changes for the specifications.

Alternative Methods - It is understood that there may be specific implementation methods that are expressed or implied by the recommendations here that may if adopted literally, not be the best way to implement the stated objectives in the opinion of the responsible project group. The Unique ID task force requests that a suitable implementation alternative be developed by the relevant project group that meets their preferences and still accomplishes the objectives of the task force suggestion. Additional collaboration and solution-seeking is welcome.

Want to Get Involved?

Have questions? Want to help with future efforts to ensure consistency of identifiers between specifications? Leave a comment or question in the Unique ID Task Force forum.


Andrew Alfers, VitalSource
Matthew Ashbourne, McGraw-Hill
Jimmy Asher, SAFARI Montage
Cary Brown, IMS Global Learning Consortium
Wesley Burt, Learn Platform
Amy Colucci, McGraw-Hill
Linda Feng, Unicon
Andy Fisher, PSU
Marc Fleischeuers, Kennisnet (Netherlands)
Andy Foglia ,Engrade
Andrew Gardener, The University Of British Columbia
Ryan Gravette, Idaho Digital Learning
John Grubbs, Google
Viktor Haag, D2L
Dylan Havard, Blackboard
Keith Hazelton, University Of Wisconsin
Seth Holm, Elsevier
Chris Houston, SEI
Jace Howard, Blackboard
Yeona Jang, Explorance
Jason Kaetzel, Indiana University
Jeff Longland, The University Of British Columbia
Jorge Lugo, Google
Pan Luo, The University Of British Columbia
Greg Mahaffey, Wisconsin eSchool
Ganesh Mali, Pearson
Leslie McCafferty, IMS Global Learning Consortium
Gregory Nadeau, PCG
Padraig Ohiceadha, Houghton Mifflin Harcourt
Kelli Pardo, Itslearning (Co-chair)
Etienne Pelaprat, Unizin
Matthew Richards, Infinite Campus
Gabrielle Sanderson, Renaissance
Aaron Silvers, Elsevier
Peter Soderquist, Elsevier (Co-chair)
Tim Trinidad, Schoology
Anthony Whyte, University Of Michigan
Michael Wood, University of California






Caliper Analytics Specification 1.1. Whyte, Anthony; Haag, Viktor; Feng, Linda; Gylling, Markus; Ashbourne, Matt; LaMarche, Wes; Pelaprat, Etienne. IMS Global Learning Consortium. URL:

Caliper Analytics Specification 1.2. Andrew Gardener, Yeona Jang, Dan Carroll, Daniel Green, Sam Sciolla, Lance E Sloan, Kara Armstrong, Markus Gylling, Linda Feng, André N'guettia, Eric Preston, Oxana Jurosevic, Whyte, Anthony, Haag, Viktor, Feng, Linda, Pelaprat, Etienne, IMS Global Learning Consortium.
Caliper 1.2 Implementation & Best Practices Guide
Caliper 1.2 Conformance and Certification Guide

Learning Tools Interoperability (LTI): Core Specification v1.3. C. Vervoort; N. Mills. IMS Global Learning Consortium. March 2018. URL:

OneRoster Specification and REST Binding v1.1, P.Nicholls and C.Smythe, IMS Global Learning Consortium, Inc., April 2017, URL:

OneRoster 1.1 CSV Tables, P.Nicholls and C.Smythe, IMS Global Learning Consortium, Inc., April 2017,

Question and Test Interoperability v2.2 Implementation Guide. Jérôme Bogaerts (OAT), Thomas Hoffmann (ETS), Rob Howard (NWEA), Wilbert Kraan (JISC/CETIS), Mark McKell (IMS), Colin Smythe (IMS), IMS Global Learning Consortium. September 2015. URL:

Question & Test Interoperability Results Reporting v2.2. Colin Smythe, IMS Global (UK), Mark McKell, IMS Global (USA), Wilbert Kraan, JISC (UK). IMS Global Learning Consortium. August 2016. URL: 

Anonymization. The act of assigning a randomized username to a person through a non-repeatable process.

Anonymous ID. Username obtained through the process of anonymization.

Context. General term for describing where or in what state something is done; could be the course, a course section, or where specifically in the course.

Lis_person_sourcedid. This field contains the LIS identifier (unique identifier) for the user account that is performing this launch.

Pseudonym. Username obtained through the process of pseudonymization.

Pseudonymization. The act of assigning a randomized username to a person through a repeatable process.

Resource Link. General term for an entity used to generate clickable links within a user interface. 

Sourcedid. Parameter used in LTI and certain other IMS specifications to handle user identifiers.

Tool Consumer. Learning Management System or other platforms that consume the application or resources.

Tool Provider. External tool or content that is consumed by the tool consumer.

User_id. Parameter used in LTI and certain other IMS specifications to handle user identifiers.

Username. Synonyms: user id, login name, logon name, sign-in name, sign-on name. Per A unique sequence of characters used to identify a user and allow access to a computer system, computer network, or online account. Usernames may be defined in a certain scope (for instance, a school or company).