Making Federation Work for Libraries: Four Experts on Privacy, Trust, and Quick Wins

Zhaneille: It’s an ecosystem barrier. In academia, IP authentication is a built-in, longstanding access method supported by software like EZproxy and services like VPN. Librarians and most vendors also license access based on institutional IP ranges. 

Shifting the access model from IP to federated access can create friction points for academic libraries, including patron privacy, financing, identity management, and integration complexity.

Amanda: A lot of it comes down to inertia. Libraries have spent decades building access models, license terms, and workflows around IP authentication. It is comfortable, predictable, and deeply woven into how e-resources are managed. It’s the “if it isn’t broken, don’t fix it” approach, even though we all know it’s showing its age.

But the deeper issue isn’t solely the technology. My experience working with academic libraries tells me it’s also largely about perception and partnership. 

Federated identity is often perceived as out of step with library privacy policies or licensing language, and there hasn’t been enough sustained partnership between libraries, vendors, and federations to change that view. Without a shared understanding of what’s needed by libraries, and implementations that reflect those nuances, it’s easier to fall back on IP.

Albert: I’d defer to my library colleagues for the real insight. My outsider perspective is that it comes down to two and a half reasons:

1. Institutional momentum to resist change: Change is hard, but changing what has worked for decades is even harder.

2. Lack of understanding/trust of alternate options: I hear all the time people equate “Shibboleth” with “Federation”. There seems to be a widespread misconception that to implement federation, one must use Shibboleth, or that Shibboleth is federation.

2.5. Privacy concerns: I include this as half a reason because while it is probably the most frequently cited reason, moving away from IP authentication does not necessarily compromise privacy. The reality is more nuanced than that.

Zhaneille: Librarians are most concerned about patron privacy and anonymity. Libraries worry that vendors can access identifiable user data (PII) and track individual usage. A federation comes across as a bit of a black box to libraries. Anonymity can be preserved through good institutional policy, and the use of privacy-preserving attributes and licenses can be negotiated to curb data misuse by vendors.

Amanda: The concern I hear most often is that federated access will expose more information about users than libraries are comfortable sharing. In some cases, that’s not entirely wrong. Depending on the implementation, the standard attribute release in a federation can include more personal data than a library might expect or want.

The reality is, most library-oriented vendors don’t need that level of detail. In library research scenarios, the majority of expected functionality can be fully supported through pseudonymous identifiers.

A lot of progress could come from simple, shared conversations between IT and library teams about privacy goals and data release. Once there’s mutual understanding around pseudonymous identifiers and how they work, it’s easier to see federated access as a privacy enhancement, not a compromise with library-held tenets about user privacy and confidentiality of research.

Zhaneille: From an academic library perspective, success needs to include increased knowledge and use of privacy-preserving attributes. Also, we (libraries and vendors) would have adopted an attribute-release baseline policy that can be implemented in licensing. 

Amanda: To me, success looks cultural more than technical. It’s when libraries feel confident taking part in identity and access (IAM) conversations — and when IT teams see them as key stakeholders in the university’s identity and security program. 

We’ll know we’re getting there when IT and IAM teams, as well as academic libraries, genuinely work side by side, bringing their own expertise and values. That’s when the model really starts to work.

Albert: First, success will involve the identity federation community, library community, and publishers establishing forums to share and shape interoperable solutions (policy, practice, as well as technical) together. Secondly, there are real-world implementations making use of these shared solutions to prove they work.

James: I think users will appreciate having a clearer understanding of the privacy protections federated access can provide by having the opportunity to approve or reject a clearly articulated, minimal set of attributes an IdP discloses at authentication time. This is hit or miss today, and that helps propagate the privacy concerns surrounding authenticated access when a user does not have visibility into the attributes they are implicitly releasing.

Zhaneille: We’re working on a quick win right now — joint messaging from a librarian, vendor, and federation manager to demystify federated authentication technology and frame it around library values. Adding licensing terms that acknowledge and permit or communicate language for implementing federated access, groups like Seamless Access have spearheaded this action.

Amanda: How might we increase representation of academic library policies and needs at the tables where federation policy and practice are developed? As federations evolve their offerings year over year, incorporating library perspectives can really strengthen understanding and trust across the community.

One of the biggest quick wins would be around privacy. If libraries and IT teams can agree to start with privacy-preserving defaults — like using pseudonymous identifiers and minimal attribute release — that single step will build a lot of trust. In practice, that might include bringing librarians into the collective journey toward adopting Access Entity Categories.

Beyond that, visibility matters. When libraries see real-world examples of peers who have implemented federated access successfully and kept user data protected, it helps shift the conversation from theory to practice.

Albert: We need to commit to showing up at each other’s places of gathering regularly and to keep the dialogue growing. It has already started. We just need to commit to maintaining it.

Zhaneille: Libraries can share their real-world experiences (access provisioning versus access restrictions by patron group) and document their privacy-preserving expectations.  Service providers can implement “industry-standard” solutions, and federations can build standards that libraries, vendors, and federation operators can collectively support and maintain.

Amanda: Collaboration is really the only way we move forward — partnership builds resilience.
For academic libraries, this might mean getting more involved in conversations where IAM decisions are being made and sharing what has worked with peers facing similar challenges. 

For service providers and identity providers, this means bringing libraries into the design process as real stakeholders — not just end-users. 

And for federations, it’s about keeping the doors open, creating spaces where these groups can come together and make the technical pieces feel practical and meaningful for the people managing access every day.

Albert: I have a slightly different take on “stakeholder group.” Campus IAM and IT teams need to reach out to their libraries and understand what libraries really need (as opposed to issuing security mandates without understanding the implications). 

Libraries need to better understand cybersecurity and other technological challenges that are overwhelming most IT organizations today, and hopefully compromise where possible. 

Publishers could really help by aligning access control models across the industry and proposing and  InCommon-compatible standards. This isn’t that far-fetched. The Access Entity Categories are real-world examples of that kind of work. The federation needs to recognize that, ultimately, what we do is about enabling seamless, secure, and scalable access to resources for users. 

In other words, this is about the user and the resources. IAM is a tool and a technique. It’s not the goal.