This document provides a description of the journey that ensues from the time that your institution signs the InCommon Participation Agreement. This journey will likely raise issues for various areas of your institution, potentially affecting technology, policy, and operations. None of these are particularly onerous; your institution has probably already addressed most of them. Here's your itinerary:

Sign the Participation Agreement

InCommon's "common framework" creates multilateral trust among all federation participants, facilitated by the Federation Operator, to exchange identity information in a secure manner. Service Providers trust Identity Providers to provide accurate information, and Identity Providers trust Service Provides not to misuse the information they receive. Community Members trust both Identity Providers and Service Providers to respect their privacy, making use of their identity information only as needed, according to legal and institutional policy. Trusted Relationships for Access Management: The InCommon Model provides a comprehensive introduction to this framework, including definitions of many of the terms used in this document.

By signing the Participation Agreement, your institution agrees to comply with multiple aspects of that multilateral trust, including:

• Deployment of conformant software
• Use of common syntax and semantics for Identity Assertions
• Provision of accurate information for the Trust Registry
• Provision of accurate contact information
• Respect for intellectual property rights
• Respect for privacy of identity information
• Adherence to Baseline Expectations for the mature and secure operation of IdPs and SPs

Baseline Expectations establishes further requirements related to the operation of your institution's Identity Providers (IdP):

• The IdP is operated with organizational-level authority.
• The IdP is trusted enough to be used to access the organization’s own systems.
• Generally-accepted security practices are applied to the IdP.
• Federation metadata is accurate, complete, and includes site technical, admin, and security contacts, MDUI information, and privacy policy URL.

and Service Providers (SP):

• Controls are in place to reasonably secure information and maintain user privacy.
• Information received from IdPs is not shared with third parties without permission and is stored only when necessary for SP’s purpose.
• Generally-accepted security practices are applied to the SP.
• Federation metadata is accurate, complete, and includes site technical, admin, and security contacts, MDUI information, and privacy policy URL.
• Unless governed by an applicable contract, attributes required to obtain service are appropriate and made known publicly.

Baseline Expectations also establishes requirements for the Federation Operator, among them being that "Good practices are followed to ensure accuracy and authenticity of metadata to enable secure and trustworthy federated transactions." The first of these practices is to validate that your institution is what it claims to be. Upon receipt of a signed Participation Agreement, the Federation Operator will reference publicly-available information sources, such as those listed in Accrediting Agencies Recognized by InCommon, to verify this.

Establish Organizational Contacts

The Federation Operator's second task is to the establish identities of the people who will have the authority to perform various functions on behalf of your institution. These are:

• Executive Contact. This is the person who is authorized to speak on behalf of your institution for issues relating to its contractural agreement with InCommon. This is typically the CIO or similar institution-level officer who signed the Participation Agreement, but that may vary, depending on your institution's organizational structure.
• Site Administrator. Designated by the Executive Contact, this is the person who approves metadata submissions for all of your institution's IdPs and SPs. This person is also InCommon's primary contact for operational, technical, and security issues relating to your institution's IdPs and SPs and its participation in InCommon overall. For business continuity reasons, institutions are strongly encouraged to designate two Site Administrators.
• Delegated Administrator. Designated by the Site Administrator, this is a person who has responsibility for one or more of the institution's SPs. This person perpares metadata submissions for their SPs, subject to approval by the Site Administrator. Any number of Delegated Administrators may be designated.
• Billing Contact. This is the person who will receive billing invoices from InCommon.

After validating the identity of your institution, the Federation Operator will arrange a telephone call with your Executive Contact to issue their login credentials for InCommon's site administration tools, and to establish the identities and phone numbers of the institution's Site Administrators. The Federation Operator then arranges phone calls with each of the Site Administrators to issue their credentials for InCommon's site administration tools.

Deploy Software

It is strongly recommended that you utilize software produced by Internet2's Trust and Identity in Education and Research (TIER) initiative in your service offerrings. This standards-based software has been configured for optimal use in InCommon and has been used successfully by many of its participants.

Acknowledging that there are many reasons why the use of TIER software components is not always practical, however, there are multiple resources to help you, including:

• InCommon's Federation Technical Guide
• Identity Provider Strategies for Common Campus Environments
• SAML V2.0 Implementation Profile for Federation Interoperability
• Upcoming resources from the Deployment Profile Working Group

Register Federation Metadata

Federation metadata is the trusted registry of IdPs and SPs operated by participants for use within the federation. It no only provides technical information to enable interoperation, links to support contacts and document, etc., it also includes information to enhance mutual trust, such as responsible parties and certifications achieved.

Getting your metadata right will make your life much easier. Time spent now will pay you back over the lifetime of your IdPs and SPs; don't skimp on this task. See Metadata Administration for all the details.

Congratulations! You Are Now Up and Running!

You and your user community are now reaping the benefit of federation. Congratulations! Your journey, though, has just begun...

Keeping Current

The InC-Ops-Notifications@incommon.org mailing list is used by InCommon Operations to send important notifications about modifications to the metadata generation system, service interruptions, and any other important technical announcements as they occur. All official InCommon Site Administrators are automatically subscribed to this list as a requirement to participation in InCommon services. Any other technical contacts may also subscribe. See InCommon Mailing Lists for other lists covering general announcements, as well as discussions of collaboration, implementation, and technology related to InCommon.

Internet2 convenes two conferences, each on a yearly basis, are great ways to meet your peers, as well as to learn first-hand about, and to influence, current activities related to InCommon.

• Internet2 Global Summit, held in the Spring, is a leading forum to support and drive the advancement of research and education, spur next-generation innovation and accelerate global discovery. The Summit convenes CIOs and other leaders from institutions around the world in an environment of open engagement, free exchange, partnership and collaboration.
• Internet2 Technology Exchange, held in the Fall, is a premier technical event in the global R&E community, convening the community’s technology visionaries—including chief technologists, scientists, engineers, architects, operators and students from around the U.S. and the globe.

Recommended Certifications

The Research and Scholarship (R&S) Entity Category streamlines access to the growing list of federated resources that support research and scholarship by faculty, students, and others have need for those resources. R&S-certified Service Providers comply with speicfic standards for privacy protection and operational maturity, and request only low-risk identity attributes from IdPs.  R&S-self-certified Identity Providers are configured to release those low-risk identity attributes to R&S-certified SPs without further institutional approval. If your institution operates such an SP, obtaining R&S certification will facilitate access for its users worldwide, and asserting R&S certification for your IdP will allow R&S-certified SPs to streamline access for members of your community. See How to Apply for the Research and Scholarship (R&S) Entity Category for more information.

The Security Incident Response Trust Framework for Federated Identity (SIRTFI) is an international standard to enable the coordination of incident response across federated organizations. SIRTFI provides a framework for effective incident response collaboration among federation and interfederation participants. One compromised account can create a security problem for a multitude of services across the interfederation community. When an organization complies with the SIRTFI framework, it agrees to participate in a federated incident response process.  SIRTFI stipulates high-level practices and procedures, and identifies organizations that are capable of participating in a federated incident handling process. Federation participants that comply with SIRTFI are marked in the federation’s metadata, raising the bar for operational security across federations. See Asserting SIRTFI for more information.

Community Involvement

Get involved! InCommon is operated "by and for" its community, so there are many opportunities to participate at various levels of commitment in the creation of InCommon's future.

• Working groups are generally the best place to start; participation is usually open to all interested parties. Many of InCommon's governance and advisory groups rely on time-bounded working groups to address various issues of current interest. Your time commitment is generally an hour-long conference call every week or two, plus whatever additional time you choose to contribute according to your specific interests. See Trust and Identity Working Groups List for current working groups; new groups are announced to the participants@incommon.org mailing list. 
• InCommon has standing advisory groups with more formal membership criteria and processes. Solicitations for new members are generally announced on the participants@incommon.org mailing list. See the advisory groups' web sites for more information:
  • InCommon Technical Advisory Committee
  • Community Trust and Assurance Board (CTAB)
  • InCommon Steering Committee
  • CACTI - Community Architecture Committee for Trust and IDentity
  • Trust and Identity Program Advisory Group
• REFEDS (the Research and Education FEDerations group) is the voice that articulates the mutual needs of research and education identity federations worldwide. The group represents the requirements of research and education in the ever-growing space of access and identity management, working with and influencing the direction of other organisations on behalf of our participants.REFEDS participants are from a wide range of backgrounds, but all share an interest in developing access and identity management technology, policies and processes. Many participants represent national identity federations and many come from National Research and Education Networks (‘NRENS’).