Main Nav

We use two multi-valued attributes to record entry level restrictions and attribute level restrictions. Since FERPA is only one of many reasons you may want to restrict the release of an entry or an attribute, being able to record multiple reasons rather than just a "hasFERPA" type attribute seemed the better approach. ou level ACI's are used to prevent entry release. Entry level ACI's are used to prevent release of individual attributes. Granular level release (public, USC-only, private) is possible, but we don't allow users to directly alter those settings at this time so public and private are the only ones actively used at this time. The Student and Payroll systems are considered to be the systems of record for the privacy settings. When an application is approved by the data stewards to access private attributes and entries the service account it uses for querying is added to a group so that it can access them despite the ACI's. This solution doesn't require the creation of a lot of attributes, but the number of entry-level ACI's created is dependent on the number of individuals who choose custom privacy settings. This hasn't proven to be a problem. This has been in place here for 8 years but the approach was initially developed and implemented elsewhere 13 years ago. There is likely an old Internet2 or EDUCAUSE presentation on it in the ether somewhere that gives more details. Trying to support this kind of thing in a robust LDAP product can be done, but I think it remains to be seen how to accomplish this in something like Active Directory. This is a challenge for us as we are seeing a trend toward more AD-centric solutions coming to campus. In the past such products often required only authentication, but now they want attributes as well, some of which are restricted. If not actual attributes in eduPerson, perhaps some guidelines could be written that would be helpful to those struggling with this. Regards, Brendan Bellina Mgr, IdM USC

Comments

There appears to be two schools of thought for enforcing a student's election for privacy under FERPA, and we have tried both. The first method we used was hiding selected students via ACI at the directory. What we do now is populate an attribute that is expected to be consulted by affected applications. In either case I would find a standard attribute useful. I do think making it generic is a good idea. Call it eduPersonPrivacyStatus or something else privacy related and multi-valued. All we do is populate an attribute with the values 'public' or 'private', the latter indicating that the student has elected FERPA protection. We used to base an ACI on the same attribute. I'm not a FERPA expert and was not aware of the per attribute options. I'm assuming that we offer the students all or nothing to keep it simple.
Kieth We carry an institutional schema value created for defining the FERPA privacy status as many others do. I suspect that there are multiple ways that institutions who use this form of privacy protection choose to implement it. Probably everyone who has used a privacy flag has run into a conflict with students who choose to mark their records as private only to find that they are not listed in any directory with anonymous access. There is indeed complexity in being able to define partial releases of information as well as determining the default behavior. For simplicity, carrying a single value attribute would seem to be a good common schema addition for eduperson (IMHO). Barry Are there use cases for an attribute conveying FERPA status? It seems that a number of campuses have independently created attributes to carry a student's FERPA status. Are there use cases out there that would show significant value in standardizing and adding such an attribute to eduPerson? Clearly this is a US-centric issue. Note the complication that FERPA protections can be invoked on particular attributes, not just globally on the user. --Keith Hazelton
Message from benjamin.oshrin@the.oshrinium.net

Kieth We carry an institutional schema value created for defining the FERPA privacy status as many others do. I suspect that there are multiple ways that institutions who use this form of privacy protection choose to implement it. Probably everyone who has used a privacy flag has run into a conflict with students who choose to mark their records as private only to find that they are not listed in any directory with anonymous access. There is indeed complexity in being able to define partial releases of information as well as determining the default behavior. For simplicity, carrying a single value attribute would seem to be a good common schema addition for eduperson (IMHO). Barry Are there use cases for an attribute conveying FERPA status? It seems that a number of campuses have independently created attributes to carry a student's FERPA status. Are there use cases out there that would show significant value in standardizing and adding such an attribute to eduPerson? Clearly this is a US-centric issue. Note the complication that FERPA protections can be invoked on particular attributes, not just globally on the user. --Keith Hazelton
Message from benjamin.oshrin@the.oshrinium.net

There appears to be two schools of thought for enforcing a student's election for privacy under FERPA, and we have tried both. The first method we used was hiding selected students via ACI at the directory. What we do now is populate an attribute that is expected to be consulted by affected applications. In either case I would find a standard attribute useful. I do think making it generic is a good idea. Call it eduPersonPrivacyStatus or something else privacy related and multi-valued. All we do is populate an attribute with the values 'public' or 'private', the latter indicating that the student has elected FERPA protection. We used to base an ACI on the same attribute. I'm not a FERPA expert and was not aware of the per attribute options. I'm assuming that we offer the students all or nothing to keep it simple.
Kieth We carry an institutional schema value created for defining the FERPA privacy status as many others do. I suspect that there are multiple ways that institutions who use this form of privacy protection choose to implement it. Probably everyone who has used a privacy flag has run into a conflict with students who choose to mark their records as private only to find that they are not listed in any directory with anonymous access. There is indeed complexity in being able to define partial releases of information as well as determining the default behavior. For simplicity, carrying a single value attribute would seem to be a good common schema addition for eduperson (IMHO). Barry Are there use cases for an attribute conveying FERPA status? It seems that a number of campuses have independently created attributes to carry a student's FERPA status. Are there use cases out there that would show significant value in standardizing and adding such an attribute to eduPerson? Clearly this is a US-centric issue. Note the complication that FERPA protections can be invoked on particular attributes, not just globally on the user. --Keith Hazelton
Message from benjamin.oshrin@the.oshrinium.net

There appears to be two schools of thought for enforcing a student's election for privacy under FERPA, and we have tried both. The first method we used was hiding selected students via ACI at the directory. What we do now is populate an attribute that is expected to be consulted by affected applications. In either case I would find a standard attribute useful. I do think making it generic is a good idea. Call it eduPersonPrivacyStatus or something else privacy related and multi-valued. All we do is populate an attribute with the values 'public' or 'private', the latter indicating that the student has elected FERPA protection. We used to base an ACI on the same attribute. I'm not a FERPA expert and was not aware of the per attribute options. I'm assuming that we offer the students all or nothing to keep it simple.
Kieth We carry an institutional schema value created for defining the FERPA privacy status as many others do. I suspect that there are multiple ways that institutions who use this form of privacy protection choose to implement it. Probably everyone who has used a privacy flag has run into a conflict with students who choose to mark their records as private only to find that they are not listed in any directory with anonymous access. There is indeed complexity in being able to define partial releases of information as well as determining the default behavior. For simplicity, carrying a single value attribute would seem to be a good common schema addition for eduperson (IMHO). Barry Are there use cases for an attribute conveying FERPA status? It seems that a number of campuses have independently created attributes to carry a student's FERPA status. Are there use cases out there that would show significant value in standardizing and adding such an attribute to eduPerson? Clearly this is a US-centric issue. Note the complication that FERPA protections can be invoked on particular attributes, not just globally on the user. --Keith Hazelton
Message from benjamin.oshrin@the.oshrinium.net

Message from benjamin.oshrin@the.oshrinium.net

Close
Close


EDUCAUSE Connect
View dates and locations

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

EDUCAUSE Institute
Leadership/Management Programs
Explore More

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.