Amanda Ferrante’s Scholarly Kitchen article, “Advancing Federated Identity in the Library Ecosystem”, is a useful prompt. It is about federated authentication for licensed e-resource access: SSO, SAML, Shibboleth, OIDC, SeamlessAccess, IP recognition, publisher and aggregator platforms, attribute release, and the stubborn gap between federation availability and day-to-day adoption.
E-resource access really does need better federation practice, and Ferrante is right to point at affiliation, entitlement, privacy, proportionality, and organisational adoption as the difficult bits.
I want to widen the lens, not argue with it.
The phrase I keep reaching for is federated library privilege. I do not mean that as a proposed standard. What matters is the distinction it forces us to make:
Federated library privilege is the ability for an authorised library, institution, consortium, or identity service to make a bounded, privacy-respecting assertion that a person is entitled to a defined library-mediated service, and for another party to rely on that assertion for a specific purpose.
Put more plainly: who is allowed to vouch, what exactly are they vouching for, who is allowed to believe it, and for what action?
The same question turns up in e-resource access, public library access, consortial borrowing, resource sharing, reciprocal borrowing, shared discovery, and patron services that cross institutional boundaries.
Who is entitled to vouch?
Personal identity, institutional identity, library privilege, and federation are related, but they are not the same thing:
Personal identity answers: who is this person?
Institutional identity answers: what relationship does this person have with this institution?
Library privilege answers: what is this person entitled to do through library-mediated services?
Federation answers: who else is allowed to rely on that assertion?
A campus identity provider may be able to say that someone can authenticate as a member of the institution. A library service may need a different assertion: this person falls within a class of users entitled to a particular service under a licence, policy, borrowing agreement, or reciprocal access arrangement.
Not merely identity, but service-specific entitlement.
Entitlement is doing a lot of hidden work
Ferrante’s article is useful precisely because it names affiliation and entitlement as central to the e-resource access problem. But the word “entitlement” is doing a great deal of work there. The next question is how that entitlement is made, scoped, transported, relied upon, and governed.
Authentication can tell a service that a person has successfully logged in. Authorisation can tell a system whether a requested action should be allowed. Entitlement is often carried through authorisation systems, but in library settings it is frequently under-modelled. It gets treated as something inferable from identity or affiliation, when it often depends on resource-specific, policy-specific, and institution-specific conditions.
A user is not simply “entitled” in the abstract. They are entitled to something: a licensed article, a database, a borrowing service, a digital loan, a reciprocal access arrangement, a request workflow. That entitlement depends not only on who they are, but on the resource or service being accessed, the policy or licence that governs it, and the institution prepared to stand behind the assertion.
It is not enough to ask what can be inferred from the authority that minted the login token. The token may establish an institutional relationship, but the library often has to add the service-specific judgement: this person is covered by this licence, belongs to this borrower class, is in good standing for this transaction, or may use this particular shared service.
That is the layer I am trying to name with “federated library privilege.” I do not mean it as a replacement for entitlement, or as a new standard term. I mean it as a way of making the entitlement layer visible: the bounded, library-specific claim that a person may perform a particular library-mediated action, and that another party may rely on that claim.
Metadata is not entitlement
The same point matters for resource sharing.
There is a current tendency to imagine that the next breakthrough will come from ever larger metadata aggregations: bigger shared indexes, larger knowledge bases, more complete holdings graphs, more ways of knowing who appears to hold a copy of something.
Those things are useful. Discovery matters. Knowing that a copy may exist somewhere is not trivial.
But it is only half of the equation.
A shared index can help answer:
Who might have this?
It does not, by itself, answer:
Can I give this to you, on what terms, under whose authority, and with what obligations attached?
That second question is the harder library question. It is where identity, entitlement, policy, licence, local rules, reciprocal agreements, copyright posture, delivery mechanism, audit, and institutional risk all meet.
Large aggregations hosted “out there” can look impressive because they make the discovery problem visible at scale. They may know that a library holds something, but not whether that library may lend it, digitise it, supply it, lend a surrogate, lend it only to certain classes of users, or rely on another institution’s assertion about the requester.
Resource sharing does not only need better ways to discover possible supply candidates. It needs better ways for institutions to express the conditions under which a resource may be supplied, and the classes of users or requests for which those conditions apply.
In other words: metadata aggregation can find the door. Entitlement tells us whether we are allowed to open it.
Mediation is often a sign of an under-modelled entitlement space
This is also why traditional interlibrary loan has remained mediated.
That word matters. In OpenRS discussions, we have tended to describe ILL as mediated not because staff intervention is a quaint legacy habit, but because the final lending decision often depends on context that is not fully expressed in the request metadata.
A human can look at the request, the requester, the supplying institution’s policy, the item type, the apparent use case, the format, local restrictions, licence position, copyright posture, delivery route, risk, and precedent, and then decide whether supply is appropriate. That judgement is doing entitlement work, even if the system does not name it that way.
Mediation is what happens when the entitlement model is still implicit.
Direct Consortial Borrowing changes the cost profile by narrowing the problem. For standard print lending between trusted partners, we can model enough of the entitlement and policy space to make many decisions automatically: this patron class may request this item type, from this lending context, through this circulation pathway, under these rules.
That is why DCB can reduce staff cost for routine print sharing. It is not magic automation. It is the result of making a previously implicit entitlement model explicit enough for systems to rely on.
But the model is still narrow. It works because the domain is constrained. Once we move into a mixed environment of print, digital, CDL, licensed material, scans, chapters, articles, local exceptions, public-library users, academic users, reciprocal borrowers, and consortium-specific policies, the entitlement space becomes richer again.
The long-term challenge is not to remove mediation everywhere. It is to decide which parts of the mediation judgement can be modelled, communicated, audited, and safely automated, and which parts should remain human because the policy, risk, or context is genuinely too complex.
Identity is not entitlement
A person may have a personal identity through university IAM, local library registration, ORCID, email, government ID, or some other mechanism. A library service often needs a more specific assertion: current patron, affiliated researcher, authorised borrower, walk-in user, alumni user, staff member, reciprocal borrower, or a member of a class covered by a licence, local policy, or consortium agreement.
The relying service often does not need the full personal identity. It needs a bounded assertion sufficient for the service being requested.
For e-resource access, that might mean knowing that the user is affiliated with a subscribing institution or belongs to an eligible class for licensed content.
For borrowing, it might mean knowing that the patron’s home library recognises them, considers them eligible, and is prepared to stand behind the transaction.
The better question is often not “who is this person?” but “who is prepared to vouch for this person’s entitlement, and on what terms?”
E-resource access is already about privilege
Ferrante’s article is especially helpful here because it shows how much entitlement is being carried through the login path.
The access problem she describes is not just that users struggle to find the right login button. In many workflows, the choice of login route is doing more than authentication. It is being used to infer affiliation, entitlement, licence coverage, and sometimes even the acceptable access pathway.
If affiliation and entitlement were cleanly separated, the login button would matter less. Authentication would establish a trusted subject. A library entitlement layer would then answer the more specific question: is this person entitled to this resource or service, under this policy, from this institution, in this context?
The trouble is that library entitlement is often treated as something that falls out of institutional authentication. Sometimes it does. Affiliation can be a valid basis for entitlement. But the proxy works until it doesn’t. A person may be able to authenticate with an institution without being entitled to every library-mediated service. Conversely, some library-entitled users, including walk-ins, alumni, reciprocal borrowers, public-library patrons, consortium users, and visiting researchers, may not map neatly onto the institution’s primary IAM categories.
Authentication gives you a subject. Affiliation gives you an institutional relationship. Entitlement requires a resource-specific or service-specific judgement. Federation determines who else may rely on that judgement.
This is the layer I am trying to name with “federated library privilege”: not identity itself, and not affiliation alone, but the bounded, library-specific entitlement judgement that another service is allowed to rely on.
SAML, Shibboleth, OIDC, SeamlessAccess, and related federation infrastructure matter because they can transport those assertions in standard ways. They can support location-independent access, proportional attribute exchange, and more consistent access flows than IP recognition and proxy-only models.
But a protocol on paper is not a working access arrangement. Libraries, institutional IAM teams, publishers, service providers, and federation operators still have to agree what is being asserted, how much data is necessary, how it should be configured, and how the access path should feel to the user.
MOBIUS DCB as a proof case
The MOBIUS example belongs near this conversation because it exposes the same trust pattern at a different library service boundary.
Over the past two years, EBSCO and K-Int have been working with the MOBIUS consortium in Missouri on Direct Consortial Borrowing (DCB) architecture, developed in the context of the OpenRS project and its wider resource-sharing governance model.
The goal is easy to describe and hard to do well: let patrons discover, request, place holds, borrow, and return materials across a wide-area group of libraries as if the consortium were, in some operational sense, a virtual circulation environment over mixed type consortia.
That OpenRS context matters. OpenRS is not just a code label; it is the open-source project and governance setting for this work, aimed at resource sharing across heterogeneous institutions and systems rather than folding the problem back into one local LMS/LSP.
MOBIUS is not a single-system monoculture. The participating libraries operate across a genuinely heterogeneous ecosystem, including FOLIO, Sierra, Polaris, and now Ex Libris Alma. Those systems have different data models, circulation rules, patron structures, item states, APIs, and operational assumptions.
To make consortial borrowing work across that landscape, the system cannot pretend that every patron lives in one central database, or that every library has adopted the same identity provider, or that a single universal login solves the problem.
Instead, participating institutions need to attest to the standing or eligibility of their own patrons.
The MOBIUS DCB work is interesting because it makes the hidden entitlement problem concrete. It is not enough to know that a patron exists or can authenticate; the system has to know that the home library is prepared to assert eligibility for this transaction, and that another library or shared service may rely on that assertion.
In other words:
Library A knows its patron.
Library A can assert that the patron is eligible.
Library B or a shared service can rely on that assertion enough to allow a request, hold, loan, or fulfilment workflow to proceed.
The consortium can coordinate the transaction without collapsing every institution into the same local system.
In DCB work, the distinction is not abstract. It quickly becomes API design, policy mapping, patron blocks, audit trails, edge cases, and decisions about what one system is allowed to believe because another system asserted it.
Not the same protocol, but the same trust architecture
In licensed e-resource access, the relying platform needs to know that the user is affiliated with, or entitled through, a subscribing institution.
In Direct Consortial Borrowing, the relying library or shared service needs to know that the patron’s home institution recognises them, considers them eligible, and is prepared to stand behind the transaction.
These are not identical workflows. They do not require the same protocols.
They do expose the same architecture of trust: a bounded assertion by one institution, relied upon by another, for a defined library purpose.
Both raise questions of privacy and proportionality: what is the minimum assertion needed for the transaction?
Both raise questions of governance: who is entitled to vouch?
Both raise questions of adoption: which systems actually make, transport, receive, and act on the assertion?
Both raise questions of scope: what may the relying service do with the assertion, and what may it not do?
DCB is not an unrelated circulation story. It is a concrete proof case: library privilege has to cross institutional boundaries in a way that is trusted, limited, and useful.
Authentication and attestation
Another way to say this is:
Authentication asks: who has logged in?
Attestation asks: what is a trusted party prepared to assert?
For licensed e-resource access, authentication and affiliation assertions are often the centre of the workflow. A platform needs a reliable way to know that the user is connected to an entitled institution.
For consortial borrowing, the more important question may be whether the patron’s home institution is prepared to assert eligibility, good standing, and responsibility for the purposes of a specific transaction.
A home library may not need to expose a rich identity profile or make the patron legible to every external system in the same way. It may simply need to assert eligibility for a particular class of service.
Federated library privilege gives us a name for the library-specific layer between identity and action: the assertion that someone is entitled to do something through a library-mediated service.
Who is on the hook?
Federation is not just about transporting attributes.
A useful assertion carries institutional responsibility. It says, within a defined context, that another party may act on the basis of the claim being made.
In e-resource access, the question may be whether a user is covered by a licence or entitled to institutional access. The relying platform needs confidence that the access decision is grounded in a valid institutional relationship or entitlement class.
In borrowing, the question may be whether the home library stands behind the patron for request, loan, return, block, recall, loss, or policy enforcement purposes.
I am not making a legal claim about liability in any particular agreement. The architectural point is simpler: assertions are useful because someone is authorised to make them, their meaning is bounded, and another party is allowed to rely on them for a specific purpose.
The library is not merely a passive consumer of campus IAM.
Campus IAM may authenticate a person and express an institutional relationship. The library often adds a service-specific entitlement layer that campus IAM alone may not express: licensing terms, local policy, patron status, borrowing rules, walk-in access, alumni access, reciprocal arrangements, and consortium agreements.
If we ignore that layer, we miss much of what makes library federation hard and interesting.
A note on Controlled Digital Lending
The same framing matters for Controlled Digital Lending.
CDL is often discussed as a copyright, digitisation, or digital-rights-management problem. Those questions are real, but they are not the whole architecture. CDL also depends on assertions of library privilege.
A controlled digital loan requires more than a user login. A service needs to know that the borrower is entitled to borrow from the relevant library or consortium, that the institution is entitled to lend the item under its policy, that the loan is bounded by the appropriate copy-control rules, and that access is limited to the right person, for the right purpose, for the right period.
In other words, CDL combines several assertions:
- this person is a recognised patron or eligible borrower;
- this institution is the relevant lending authority;
- this item is within the institution’s controlled lending policy;
- this loan is within the allowed circulation ratio or control model;
- this access event is auditable and time-limited.
That makes CDL a sharp example of federated library privilege. The issue is not simply personal identity, and it is not simply authentication. The issue is whether a library or consortium can make a bounded, accountable assertion that a person is entitled to a specific library-mediated act of access, and whether another service can rely on that assertion without collapsing identity, policy, and lending control into one central system.
In CDL, the entitlement is not only attached to the user; it is attached to a controlled relationship between user, institution, copy, policy, access period, and audit trail.
Seen this way, CDL sits close to the same trust architecture as e-resource access and consortial borrowing. E-resource access asks whether a user is covered by an institutional licence. Direct Consortial Borrowing asks whether a patron’s home institution stands behind a borrowing transaction. CDL asks whether a library can stand behind both the patron entitlement and the controlled lending entitlement for a digital surrogate.
If we reduce federated identity to login mechanics, we miss the harder library question: how are library privileges asserted, limited, trusted, enforced, and audited across institutional and technical boundaries?
Why EBSCO should make more of this
EBSCO has an opportunity here.
Ferrante’s article rightly argues that federated access to licensed scholarly resources needs better coordination and clearer implementation patterns across libraries, publishers, service providers, federation operators, and institutional IAM teams. I agree.
But EBSCO is already close to this story through MOBIUS/DCB and the OpenRS project context around it. It does not need to reach for abstract examples of federated identity in libraries while its own customers and partners are working through one of the more interesting practical versions of the problem.
That does not mean stretching terminology until it loses meaning. DCB is not SAML, and every circulation workflow does not need to be rebranded as identity management.
MOBIUS is not merely implementing a borrowing workflow. It is demonstrating how a heterogeneous group of libraries can behave, in some respects, like a shared service environment without becoming a single institution or a single platform.
EBSCO could make more of this.
A longer-range thought: the virtual library card
If library privilege is the thing we are really trying to assert, then one possible destination looks less like a better login button and more like a portable library credential.
Imagine that when someone joins a library, the library issues a signed credential into a wallet. Not a universal identity card, and certainly not a reading-surveillance passport, but a bounded assertion: this person is a current patron, belongs to this borrower class, is eligible for this type of service, and the assertion is valid until this date unless revoked.
A lending library, CDL service, OpenRS/DCB service, or resource-sharing node could then ask the patron to present the relevant proof. The service would not need to know everything about the person. It would need to know that a trusted issuer had made a claim within a recognised trust framework, and that the claim was still valid for the transaction being attempted.
That changes the shape of the problem. Instead of asking every service to infer entitlement from whichever authentication route happened to work, library privilege becomes something that can be issued, scoped, presented, checked, and audited.
For Controlled Digital Lending, the same pattern gets more interesting. A controlled digital loan needs both sides of the assertion: the borrower is entitled to borrow, and the institution is entitled to lend this controlled digital surrogate under a defined policy and control model. In that world, the virtual library card is only one part of the transaction, but it is a useful way to think about the patron side of the entitlement.
The privacy warning matters. A library wallet should disclose the minimum necessary claim, support pairwise or pseudonymous identifiers where possible, and avoid creating a central trail of what people read. The goal would not be to make patrons more trackable. It would be to make library privilege more explicit, portable, and accountable without collapsing everything into a central identity system.
Already building from the inside
Federated identity in libraries should not be reduced to login mechanics. Library-relevant privilege has to be asserted, trusted, transported, limited, and governed across institutional boundaries.
Ferrante’s article is right to focus on the adoption gap in federated access to licensed scholarly resources. My addition is that the same trust problem is already visible in consortial borrowing and resource sharing.
MOBIUS DCB shows that libraries are not merely waiting for federated identity to arrive from the outside. They are already building practical, bounded, institutionally accountable shared trust arrangements from the inside.
Libraries have always worked through shared trust. The next generation of library infrastructure should make that trust explicit, privacy-respecting, operationally useful, and accountable to the services it enables.