Join InCommon

Trusted Relationships for Access Management

The InCommon Model

This document is curated under the Internet2 Trust and Identity Document Stewardship program. Download the official text from the Internet2 Trust and Identity Document Repository at:

Document Date: July 21, 2017


The InCommon Federation was formed in 2004 as a way of scaling the many online relationships an organization maintains when offering services to another or enabling access for its users to another’s services.

The federation provides a common, agreed-on framework to ensure trust and operational efficiencies at scale. This framework includes establishing standards for information elements and practices such as  responsible parties, contacts, security model, change management process, and incident handling. The federation operator publishes these to the community so that each participating organization only sets up their processes and infrastructure once when it joins the federation and leverages that over and over with each participating partner.

Because of this, the federation is a great facilitator of collaboration use cases involving multiple institutions. Coupled with policy adherence tags like the Research and Scholarship Entity Category, it greatly reduces the burden on individuals to navigate their own way to resources hosted at other institutions.

Basics of trust

At a high level, InCommon’s trust model is fairly simple. InCommon Participants rely on the InCommon Federation to introduce them to each other (by publishing a Trust Registry) in a “hub and spoke” configuration.                                     

Once introduced, however, participants rely on each other in a mesh configuration to exchange identity information in accordance with the agreed upon practices and in support of access control and personalization for their services.

In addition to operating the Trust Registry, the Federation Operator works alongside the participant community to continue to evolve the federation practices to ensure continued trust among participants.

The devil, of course, is in the details. Who are the “someones” and what are the “somethings” that we trust within InCommon? Why do we instill that trust; what are the “characters,” “abilities,” “strengths,” and “truths” that we rely on?

What do we mean by identity?

In identity management practices, “identity” refers to the set of information that pertains to a person. This information includes identifiers, memberships, eligibility, roles, names, characteristics, etc. Some of this information may uniquely identify that person, even sensitive Personally Identifiable Information (PII), but much of this information is not.

Note that this definition of “identity” is not the common English definition of the word1, which implies unique association with a specific individual. In fact, in the practice of identity management, unique association is often not required and, therefore, is disallowed in those instances to enhance privacy.

Who are the actors we trust?

There are two primary types of actors within the InCommon Federation:

Individuals that use services in the Federation are also actors, though not explicitly part of InCommon’s trust model. See role of the individual and PII.

What do we trust?

When one uses an online service, there are two primary actions associated with access:

  1. Authentication verifies who you are and is the act of ensuring that the person with the credential (login id for example) is the same person that the organization has on file as having permission to use that credential. The verification is done using a password or some other mechanism.
  2. Authorization is about what you can do and is the act of granting access to the authenticated individual based on role, grant number, license number, organizational affiliation and the like.

In a federated transaction, the organization that manages authentication for the individual is not the one hosting the service that the person wants to access. One organization authenticates the individual (in many cases a college or lab), and one offers services (such as a cloud provider, research collaboration, federal agency) and grants access.

To enable this transaction to happen, the organization offering a service asks the individual to identify his/her home organization and then asks the home organization to make sure the person is authenticated. The home organization is then asked to respond to the service provider with the necessary information about the person to authorize access. Information is released only if (1) the person has been properly authenticated at the time of the request, and (2) the home organization has decided to release this information. The IdP has total control of which attributes are released. At a minimum, the Identity Assertion indicates only that an anonymous member of the home organization’s community has successfully authenticated.

For example, a university library may have paid for a license to access an online journal; the journal SP only needs to know that the entity accessing the journal is indeed a member of that university community but does not need to know the individual’s name. Identity Providers and Service Providers can configure a customized exchange of additional information in a bilateral manner. For example, a textbook publisher may provide online homework and quizzes with results to be reported back to both the professor and the individual student. The R&S profile has been designed for IdPs to release a global identifier, name, and email address to any R&S Service Provider without the need for one by one configuration.

In most cases this information, called an Identity Assertion, is tightly defined in a community standard.

What are we trusting in this relationship?

Why do we trust the InCommon Federation?

Trust within the InCommon Federation is rooted in the InCommon Participation Agreement and the documents it references. The Participation Agreement is signed by all InCommon participants and legally binds them to common responsibilities and practice standards for the creation, transmission, and use of Identity Assertions. The Participation Agreement and its companion, the InCommon Federation Operating Policies and Practices (FOPP), describe InCommon’s responsibilities and practices for providing introductions of participants, as well as its administration of certifications.

Specific requirements of the Participation Agreement for all participants:

Specific requirements of the Federation Operating Policies and Practices for InCommon’s Federation Operator include:

InCommon also provides facilitation for inter-organizational issues among InCommon participants. In particular, InCommon coordinates security incident response when those incidents span multiple participants.

Only participants of the InCommon Federation are bound by the Participation Agreement. The Participation Agreement and the FOPP describe the InCommon Federation Operator’s responsibilities with respect to other federations under the overall requirements established by eduGAIN in eduGAIN Policy Framework – Constitution. A notable eduGAIN requirement is that its participant federations must “primarily serve the interests of the education and research sector.”

All Federation operators that participate in eduGAIN are required to publish a Metadata Registration Practice Statement (MRPS). This, along with the eduGAIN Policy Framework-Constitution, are the basis of trust among those Federation operators. InCommon’s MRPS is available online.


Certifications are associated with an entity’s Trust Registry entry to indicate that the Participant responsible for that entity has complied with a formal set of requirements. The certification process may allow self-assertion of compliance by the organization receiving the certification, or it may require review by the Federation Operator or some other external entity, depending on the requirements of the certification. In all cases, though, the Federation Operator is responsible for ensuring that the certification process has been followed.

Examples of certifications include the following:

Putting it all together: the trust model

The following diagrams illustrate who is trusted for what, and why. The arrows point from a trusting actor to a trusted actor.

Provision of Identity Assertions

Release of information by and IdP occurs only when of that IdP’s community members requests service from an SP. At that time, the SP requests an Identity Assertion from the IdP selected by the community member.

Participants operating SPs trust participants operating IdPs to provide accurate Identity Assertions. The Federation Operator is not part of the transaction, although the participants rely on the Federation Operator to introduce them (via the Federation Operator’s Trust Registry) to each other correctly. Use of Identity Assertions:

Participants operating IdPs trust Participants operating SPs not to misuse the information in Identity Assertions and to protect the privacy of that information. The Federation operator is not part of the transaction, although the participants rely on the Federation operator to introduce them to each other correctly.

Introductions of participants (the Trust Registry)

It is the Federation Operator’s responsibility to maintain the integrity of its Trust Registry and distribute it to all of its participants.

The Federation operator, however, is dependent on its Participants, as well as other Federation Operators, to provide correct information for later distribution, as described below.  The Trust Registry includes signed metadata describing the IdP, as well as that IdP’s digital certificate public key. Public/private key pairs are used to validate Identity Assertions and the IdPs that send them.

Creation and submission of information to the Trust Registry

The Federation Operator trusts its participants and other Federation Operators to create and submit correct information. The Federation operator does, however, provide tools and review services to help InCommon participants do this successfully; this enhances the trust that InCommon’s participants and Participants of other federations place in the Trust Registry information they receive from InCommon.

Role of the individual and PII

The InCommon trust model is explicitly among its participants and the participants of inter-federated federations. Participants operating Identity Providers, however, represent communities of individuals, and those individuals both trust and are trusted. This section discusses trust relationships that involve individual community members and how that trust is impacted when Personally Identifiable Information (PII) is involved.

Protection of authentication secrets and tokens

Participants operating IdPs trust their community members not to share the passwords, authentication tokens, secrets, etc., with others in ways that would cause them to issue false Identity Assertions.

Use of identity information

Community members trust Participants operating IdPs to release only appropriate information to authorized Participants’ SPs. They also trust participants operating SPs not to misuse the information they receive. Note that what constitutes “appropriate information” may be subject to explicit consent by the community member.

Identity Assertions will not usually contain protected PII. When they do, however, community members’ trust is enhanced by the legal provisions, such as FERPA, HIPAA, and state-specific laws, that Participants must obey.  FERPA, for example, requires participants operating IdPs to implement an opt-out mechanism for students accessing SPs that are not required for the operation of their university. Also, the use of protected PII in Identity Assertions will generally require specific contractual agreements between participants covering allowable use and protection of the information exchanged.