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, there are multiple resources to help you, including:

• InCommon's Federation Technical Guide
• Identity Provider Strategies for Common Campus Environments

Register Federation Metadata

Congratulations! You Are Now Up and Running!

Keeping Current

• Mailing lists
• Internet2 Technology Exchange
• Internet2 Global Summit

Recommended Certifications

• R&S
• SIRTFI

Community Involvement

• Working Groups
• CACTI, TAC, CTAB
• PAG, Steering
• REFEDS