InCommon is the identity federation for the United States research-and-education community, operated by Internet2. It is the trust layer that makes the “log in with your institution” button actually work across thousands of independent universities, publishers, cloud services, and research tools — not by negotiating a separate agreement between every campus and every service, but by having everyone trust one shared, signed set of rules and metadata instead.
If you have read CASRAI’s guide to Shibboleth, you already know the software side of this: Shibboleth (and products like OpenAthens) implement the SAML protocol that lets an identity provider (a campus) assert who a user is to a service provider (a publisher or tool). InCommon is a different layer entirely. It is not software a campus installs — it is the federation: the membership organization, governance structure, and metadata-aggregation service that lets a Shibboleth (or any SAML- or OIDC-capable) deployment at one institution be trusted by thousands of services it has never directly negotiated with.
What a Federation Actually Does
The hard problem in federated identity is not the authentication protocol — SAML and OIDC are well-specified and widely implemented. The hard problem is trust at scale: how does a service provider know that an assertion claiming to come from “State University” is genuine, that State University is a real, accountable organization, and that the cryptographic keys attached to that assertion actually belong to State University and not to an impersonator? Solving that one-to-one, between every pair of institutions and services, does not scale past a handful of partners. InCommon exists to solve it once, centrally, for everyone in the federation at the same time. It does this through three concrete functions:
- Entity registration. Every identity provider (an institution’s login system) and every service provider (a publisher, database, or research tool) that wants to participate registers as an “entity” with InCommon, submitting technical metadata: endpoint URLs, public keys/certificates, organizational contact information, and supported attribute and protocol bindings.
- Metadata aggregation and signing. InCommon collects all registered entity records into a single metadata aggregate, cryptographically signs it, and publishes it for federation participants to consume. A campus identity provider and a publisher’s service provider each configure their software to trust InCommon’s signature on that aggregate, rather than trusting each other’s certificates directly. That signature is the actual trust anchor: it is what lets a login built at one institution be accepted by a service that has never heard of that institution’s IT department.
- Certificate and key management. Because the whole system depends on cryptographic keys staying valid, correctly registered, and revoked when compromised, InCommon also operates certificate services and requires participants to keep their registered key material current as a condition of staying in good standing.
This is why InCommon and Shibboleth are complementary, not competing: Shibboleth (or an equivalent SAML implementation) is the software that speaks the protocol at each end; InCommon is the reason a Shibboleth deployment at any one of its member institutions is automatically trusted by any of the thousands of other participants, without a separate technical or legal agreement per pair.
InCommon Membership and Governance
InCommon is a membership federation operated by Internet2, the U.S. nonprofit research-and-education networking and technology consortium. Participants fall into two broad roles that mirror the identity-provider/service-provider split above: institutions (mostly U.S. colleges, universities, and research organizations, plus some federal agencies and nonprofit research bodies) that operate identity providers vouching for their faculty, staff, and students; and service providers — publishers, licensed databases, cloud research platforms, and campus-facing SaaS tools — that accept those institutional logins. Membership carries governance obligations, not just a technical registration: participants agree to InCommon’s policies on accurate metadata, operational responsibility for the entities they register, and (as covered below) a baseline security posture.
The Research and Scholarship Entity Category
A recurring practical problem in federated access is attribute release: an identity provider has to decide, for every single service a researcher might want to reach, exactly which personal attributes (name, email address, affiliation, a persistent identifier) it is willing to send. Negotiating that decision service-by-service does not scale any better than bilateral trust does, and in practice it is one of the most common reasons a federated login fails silently — the login succeeds, but the destination service never receives the attributes it needs to actually grant access.
InCommon, working with peer federations worldwide through REFEDS (the international federation-operator forum), supports the Research and Scholarship (R&S) entity category: a standard tag a service provider can register that signals it needs only a defined, minimal set of attributes specifically to serve the research-and-scholarship community — typically a persistent identifier, name, and email address. An identity provider that has agreed to support the R&S category can then release that minimal attribute set automatically to any R&S-tagged service, instead of requiring a bespoke attribute-release policy per service. For a researcher, this is what determines whether clicking “log in via your institution” at a repository, collaboration platform, or licensed database actually works on the first try, or fails because the institution never configured attribute release for that particular provider. InCommon also supports REFEDS Sirtfi (the Security Incident Response Trust Framework for Federated Identity), a parallel entity category oriented around security-incident coordination rather than attribute release.
InCommon Certificate Service
Separately from federation metadata, InCommon operates the InCommon Certificate Service, a member benefit that provides participating U.S. higher-education institutions with SSL/TLS server certificates, client (personal) certificates, and code-signing certificates for a flat annual membership fee rather than a per-certificate cost. The service underwent a multiyear modernization effort that concluded in 2026, moving certificate issuance to CertiNext as the underlying provider while keeping the same membership model: eligibility is generally limited to U.S. higher-education institutions with a qualifying .edu domain, with an additional path for nonprofit regional research-and-education networking organizations to join for an annual fee. This is worth distinguishing clearly from the federation-trust function above — the Certificate Service issues the TLS certificates that secure a campus’s web infrastructure generally, while federation metadata and its signing key are what establish trust for SAML-based logins specifically. An institution can be an InCommon federation participant without subscribing to the Certificate Service, and vice versa.
eduGAIN: Connecting InCommon to the World
InCommon is a national federation, scoped to U.S. participants. Research collaboration is not national, which is why InCommon also participates in eduGAIN, the global interfederation service operated by GÉANT that connects national and regional research-and-education federations to one another. Rather than requiring InCommon to negotiate direct trust with every other country’s federation individually — the same bilateral-scaling problem federation itself was built to avoid — eduGAIN lets InCommon exchange a defined subset of metadata with peer federations worldwide (the UK federation, Germany’s DFN-AAI, Sweden’s SWAMID, and dozens of others, including regional federations such as KENET in Kenya) through one interfederation layer. As of 2026, Internet2 describes eduGAIN as spanning participants from roughly 79 countries. In practice, eduGAIN is what lets a researcher at a U.S. InCommon-participating institution log in with their home credentials at a European repository or a partner university’s collaboration platform, and vice versa — without either side having joined the other’s national federation directly. Only a defined, minimal set of attributes (notably the REFEDS R&S attribute bundle) is exported into eduGAIN by default, which keeps the attribute-release scope consistent with the R&S model described above even at interfederation scale.
Baseline Expectations for Trust in Federation
Registering metadata correctly is necessary but not sufficient for trust: a federation with thousands of participants also needs a shared floor of operational and security practice, or the trust the metadata implies is not actually earned. InCommon codifies this as its Baseline Expectations for Trust in Federation, a set of mandatory requirements every participating identity provider and service provider must meet to remain in good standing. In broad terms, Baseline Expectations require identity providers to demonstrate real organizational authority and operational maturity to authenticate the users they vouch for; require service providers to maintain controls that protect the personal data and privacy of the users they receive; require all parties to keep their registered metadata (technical endpoints and organizational contacts) accurate and current; and require all parties to follow a common security-incident response protocol, aligned with the REFEDS Sirtfi framework mentioned above. Baseline Expectations effectively raised the floor for InCommon participation beyond “submit valid metadata,” and they are the practical answer to the question a research administrator or IT security reviewer is really asking when they ask whether a federated login can be trusted: not just whether the cryptography works, but whether every participant in the chain has committed to a shared, auditable standard of behavior.
InCommon vs. Shibboleth, OpenAthens, and SeamlessAccess
These four pieces solve different, complementary problems, and conflating them is a common source of confusion for anyone new to federated access:
- InCommon is the federation — the U.S. membership organization, metadata aggregate, and trust rules (Baseline Expectations) that make institutional logins trustable at scale.
- Shibboleth is open-source software that implements the SAML protocol at either end of that trust relationship — it is one of several products an institution or service can run to actually speak to the federation.
- OpenAthens is a commercial alternative to running Shibboleth in-house, offering similar SAML-based federated access along with proxy-based access management, and it also participates in InCommon-style federations.
- SeamlessAccess sits on top of federations like InCommon, providing the “where are you from” discovery service and user experience layer that helps a researcher find and select their home institution among thousands of federation participants, rather than replacing the federation trust itself.
A useful shorthand: InCommon answers “can these two organizations trust each other’s login assertions at all,” Shibboleth/OpenAthens answer “what software actually generates and consumes those assertions,” and SeamlessAccess answers “how does a user find the right login button in the first place.”
Frequently Asked Questions
Is InCommon the same thing as Shibboleth?
No. Shibboleth is open-source software that implements the SAML protocol; InCommon is the U.S. federation — the membership organization, metadata service, and trust rules — that makes a Shibboleth (or any SAML-capable) login trusted by thousands of other participants without a separate agreement per pair. An institution can run Shibboleth without being an InCommon participant, though most U.S. research and education institutions that federate do so through InCommon.
Who can join InCommon?
InCommon participation is primarily U.S. higher-education institutions and research organizations, along with sponsored nonprofit partners and service providers (publishers, database vendors, and research-tool providers) that want their platforms reachable via institutional login. Membership is administered by Internet2.
What does the Research and Scholarship entity category actually change for a researcher?
It determines whether a “log in via your institution” button works on the first attempt. If a researcher’s institution has enabled Research and Scholarship attribute release and the destination service is R&S-tagged, the minimal attributes that service needs (typically a persistent identifier, name, and email) are released automatically, instead of the login succeeding but the service failing to receive what it needs to grant access.
How is InCommon different from eduGAIN?
InCommon is a national federation scoped to U.S. participants. eduGAIN is the global interfederation service, operated by GÉANT, that connects InCommon to peer national and regional federations elsewhere in the world, so trust extends beyond U.S. borders without every federation having to negotiate bilateral agreements with every other one.
Does an institution have to pay to participate in InCommon?
InCommon federation participation and the separate InCommon Certificate Service both carry membership fees administered through Internet2; specific current pricing and eligibility (including a distinct path for nonprofit regional research-and-education networking organizations) is published on Internet2’s InCommon pages rather than fixed here, since fee schedules change.
What are Baseline Expectations for Trust in Federation?
A mandatory set of operational and security requirements every InCommon participant must meet: identity providers must have genuine organizational authority to authenticate their users, service providers must protect the data they receive, all parties must keep their registered metadata accurate, and all parties must follow a common security-incident response protocol aligned with REFEDS Sirtfi.
