Attendees:
Google doc extract of eduPersonAffiliation:
https://docs.google.com/document/d/1NXPFMxJ7ImVwRQ_HHhkD0lVZTv6-9ov0swL8KeoUAWs/edit#
Introductions
- Steve Glover (JISC) - only use ePA in a cloaked guise of scoped Affiliation. Don’t have many issues with the values as they are at the moment, but that’s because people only use a small subset. They are looking at how academic institutions in the UK that have licensing deals with publishers would use for affiliate or entitlement value to indicate a distance learning or remote student. Would they need a different tag?
- David Bantz (U Alaska) - use ePA as a blunt tool to distinguish different parts of our organizations. We have a small number of apps that use it to gate the level of access. There’s not a huge pain point; guests, contractors, consultants, visitors, etc, the loosely affiliated users are a big pain point, but not sure that additional values to ePA will be a solution. for many folks, assigning ePA values of both student and employee seems adequate; however, there is a category of employee whose employment is explicitly tied to their student status; these “student-employees” are for FEPRA purposes students, with rights not available to employees. An ePA value for this category student-employee would be useful in determining what data can be released or displayed (per FERPA).
- Ignacio Pérez (U. Malaga) - prefer ePA with the least number of values; they already get into more details via other attributes in schacUserStatus.
- Alan Buxey (myUniDays) - chair of the subcommittee, have seen the issues around ePA come up many times, and each site seems to be handling it differently. Would like to see a single recipe for how this is handled across the board. Bringing new organizations into federations mean we’ll need to expand values to account for them (e.g., military, blue light service)
- David Langenberg (U. Chicago) - see challenges with loosely affiliated individuals, as well as needing to be better able to distinguish students (K-12 vs higher ed)
- Mikael Linden (Finish ELIXIR node) - representing Global Alliance of Health to share human genome data. Strong federation background. Need how to know who is a researcher representing their home organization. Normally, when sensitive data is shared, it’s shared to a person representing their home organization. The current semantics of “faculty” are not very accurate; want more accurate information so they can make programatic use of it. They also have industry researchers that participate this and they will need to some how fit into this if possible.
- Tommy Doan (Southern Methodist University) - use ePA to categorize users, particularly for internal reporting. It was deployed over 15 years ago, and it mostly works as a multi-valued attribute for higher ed users. One of the challenges is: what value do we assign to a retiree and possibly a former student? Right now use “affiliate” but that’s not accurate enough to perform categorization or access control.
- Vivian Ota Wang (NIH) - helped write the genomic data sharing policies at NIH; was part of the group that developed the definition of everything we’re talking about. Has also been on the practical side on running data access committees. Hopes to offer practical use cases. Current example: piloting a new system for cancer registry data for people beyond academics (general public, advocacy groups). Would like to add a layer of compliance, to validate that people are holding to their data use agreements. Need built in robustness. Initially, when we’re were giving access, we gave it to individuals. Since their relationship to their institution was very transient, most of the abuses were done by them. When we switched this to requiring someone senior to vouch for them, that changed behavior.
- Scott Cantor (OSU) - here as an IdP operator and an affiliation sceptic; strongly favor use of entitlement in place of affiliation. Particularly interested in pushing for that in the library space rather than use affiliation. Affiliation likely cannot be granular enough; it is better at the ad hoc space for research projects based on broad categories. OSU does not release affiliation by default because we don’t want to see it misused.
- Eskil Swahn (Lund University and SWAMID) - Lund has an IAM solution where we make heavy use of ePA; have two different scopes: broad, automated provisioning of access to IT services with no sensitive information. Where we have entitlements for different IT services, they involve limits that are only applicable to specific categories. One pain point: there are few categories and they don’t cover all situations: we have a situation where research students fall exactly between employee and student.
- Christos Kanellopoulos (GEANT) - here in a capacity of the AI Taskforce of the European identity cloud and the AARC team; receives and consumes ePA information. In most collaborations we work in, authorization and management of access to resources happen at the research community level. Need to know what the affiliation is with the user to their home institution. Want to make sure that this can be functional in these collaborative research use cases. It kind of works now, but it’s not clear that we always get the information on exactly what it means.
- Chris Phillips (Canadian Access Federation) - activities around the ePA to enhance the controlled vocabulary, need to understand what that will look like. Need to be mindful of the previous discussions about how we ended up where we are, and how to be consistent with what we do. Encourages the group to think about the role of this schema in multiple protocols.
- Eric Goodman (U. California - central office) - coordinates SSO across the whole UC system. Specific concern is a need for “knowledge worker” - something that is not just an employee, more than a student. Also sees a lot of confusion between definition of “member” and “affiliate”.
- Meshna Koren (Elsevier) - customers ask us to implement support for various attributes; if we do that, would like to do that in a logical and scalable way. Would like to understand this attribute and whether it is actually useful or not, what is the correct use of it.
What is the ultimate goal for this group? Are we trying to do something that will allow us to manage entitlements? Or are we looking to clarify directory information?
Entitlements have their own value. Affiliation is something different. Any overlap where people use affiliation to manage their access control with the through of who is entitled to access the material is not the right way to do this.
There are privacy elements involved here.
SPs often prefer ePA because it’s a controlled vocabulary, it’s easy. Entitlement is not a controlled vocabulary and requires more work to be useful.
If people want this to be an open value, that’s what entitlement is for. We are putting that explicitly put that out of scope.
What we are trying to do is first, more precisely define the existing values, and second, define any values that are missing.
The definitions are as vague as they are because even the small group that worked on this originally could not come to consensus on what the terms mean. In the original work, it was stated that if what you’re doing today is assume .edu is good enough, then affiliation is good enough.
Suggestion: rather than further dilute this controlled vocabulary, if someone feels there needs to be more here, instead create a whole new attribute. The current affiliation values should be a broad brush. Anything more specific would belong somewhere else. Note that we have seen what happens when we add to ePA with library walk-in, which was added to ePA several years after the original set. It wasn’t disruptive because it’s mostly not used; it gets filtered out. It wasn’t disruptive, but it likely wasn’t successful either in that it isn’t generally used.
How often do we want to have these calls? Do we want to shift the times around to include different regions?