Both regulations give students the right to have their identity omitted from public directories and more. This presents a special challenge for the IAM practitioner who must provision data to applications.
FERPA is the Family Educational Rights and Privacy Act of 1974. The best source of information on this legislation, not surprisingly, can be found on the US Government’s website. When it comes to IAM, the most relevant passage is the following:
“Schools may disclose, without consent, "directory" information such as a student's name, address, telephone number, date and place of birth, honors and awards, and dates of attendance. However, schools must tell parents and eligible students about directory information and allow parents and eligible students a reasonable amount of time to request that the school not disclose directory information about them.”
Universities in the U.S. are allowed to publish elements of a student record that are not considered an invasion of privacy. However, there must be a process to make the student aware of her rights under FERPA, and provide the option to opt-out. According to the U.S. Education Department’s “FERPA for Students” website, Universities need to notify individuals of their rights and can use various methods including the student newspaper. The student must also be informed of their right to restrict the publishing of their “directory” information and the time period in which they must opt-out.
Most universities err on the side of caution and use multiple channels to communicate a student’s rights under FERPA. The University of Texas at Arlington’s FERPA website gives clear guidance on its intent to publish student “directory” information and has a link where registered students can request their information be restricted.
FIPPA is the Freedom of Information and Protection of Privacy Act. Many provinces have additional privacy legislation that can increase FIPPA’s bite in regards to privacy regulations. I’ve heard anecdotally that British Columbia has the tightest restrictions on publicizing student data. British Columbia’s FIPPA “Resource for Public Bodies” contains deep information on FIPPA’s applicability in BC. Most provinces have a similar guideline published on their websites.
As with FERPA in the U.S., FIPPA covers personal information for anyone including members of the public, students and employees. The U.S.’s FERPA is solely focused on student privacy. FIPPA does have some exceptions for employees when it comes to work-related information (work-related information would not include information like home address for example). Exceptions like this do not exist for students – for them, even their name is considered private information. The term “data banks” is used similarly to FERPA’s “directory” information. Note that there is separate Canadian legislation covering personal health information (PHIPA – the Personal Health Information Protection Act) and private sector employees (PIPEDA – the Personal Information Protection and Electronic Documents Act).
The biggest difference between FERPA and FIPPA is that FIPPA can be an “opt-in” model. So by default, student information in a data bank, cannot be made public without a student’s consent. One key to the administration of FIPPA is that the student who chooses to exercise her privacy rights under FIPPA cannot be penalized or have her academic progress affected by her decision.
The impact of FERPA and FIPPA on IAM
Privacy adds another level of complexity to the management of identity information. Data is frequently moved from the IAM system to destination applications through provisioning tools. Data is also made public through web interfaces, such as searches within the identity management system. Since some students opt-out (expressly or by default) of having their information visible, the IAM system must have a way to hide or obfuscate their data.
One way I’ve seen universities handle this issue is through a FERPA or FIPPA flag. This flag by itself can only store information – yes/no – public/private – or a date when the student “opted-out”. However, context must be included in the provisioning logic or in the application.
To hone in on the complexity this can create for IAM architects, look no further than email systems. A student clearly needs an email account in order to conduct their academic pursuits. However, if they were to appear in the address book, their FIPPA rights could be violated. The IAM and Email teams must collaborate on how provide a student email while protecting their privacy under FIPPA. The likely scenario is to set a provisioning rule to exclude students who do not consent to being displayed publically.
To formalize the process of governing provisioned data, I’ve seen “data sharing agreements” used to set the ground rules. It is an important step to “memorialize” an agreement that may need to exist beyond the tenure of the managers who agreed (for example) that fullname cannot be shown in anywhere in the application UI.
Finally I wanted to mention the complexity created by the fact that students can also be university employees. As employees, they do not have the same rights under these regulations. This brings up the person vs. persona debate – ergo, should student-employees have separate IDs for each role? Assuming one ID per person, systems need to become context-aware to handle the student persona differently than the staff persona.
At first glance it might not make sense why someone would be so concerned about having their name listed in a directory. “Big deal… someone can see who goes to school here, right?” But in reality, there are people who are being stalked and victims of domestic violence, celebrities and their relatives and people who just want to remain anonymous. While IAM systems can be designed to provide that privacy, proper IAM Governance is essential to ensuring that private data in IAM systems can be appropriately shared with other IT systems without violating the privacy rights of protected individuals.