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