Baseline Expectations for Trust in Federation

Version 2

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: http://doi.org/10.26869/TI.34.3

Document Date: November 2, 2020

Introduction

As the strategic value of Research and Education Trust Federations ever increases, from time to time it is important to reflect on, then assess and distill what forms the basis for sufficient trust amongst all participants. On that foundation, we can identify gaps and agree to changes that need to be implemented by various Federation actors in order to sustain and grow that trust.

What trust do we, as participants, need to have in the Federation? When we rely on the Federation, we are relying on other organizations to do something for us that we would otherwise do for ourselves or forgo altogether. The unique value proposition of the Federation makes possible the integration of resources, services, and users across the globe into the myriad ways that the R&E mission is undertaken.

This document describes the expectations for each of the three types of Federation actors: Identity Provider, Service Provider, and Federation Operator. Together, they express the Baseline Expectations for Trust in Federation.

Version 2 of this document continues the mission to further trust in the federation by clarifying a few security and supportability requirements.

In these statements, the terms “Identity Provider,” “IdP,” “Service Provider,” and “SP” refer to the operational entities that act in the federation and not to the organizations that operate them.

InCommon Federation Baseline Expectations

Baseline Expectations of Identity Providers

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.
1. The IdP complies with the requirements of the REFEDS Security Incident Response Trust Framework for Federated Identity v1.0 [SIRTFI].
2. All IdP service endpoints are secured with current and trustworthy transport layer encryption.
The IdP’s published metadata is accurate and complete, including site contact information (at least one each technical, administrative, and security contacts) and Login and Discovery User Interface (MDUI) information (display name, logo URL, privacy policy URL).
The IdP’s published metadata includes a current errorURL [Metadata].

Baseline Expectations of Service Providers

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
1. The SP complies with the requirements of the REFEDS Security Incident Response Trust Framework for Federated Identity v1.0. [SIRTFI].
2. All SP service endpoints are secured with current and trustworthy transport layer encryption.
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 of Federation Operators

Focus on trustworthiness of their Federation as a primary objective and be transparent about such efforts.
Generally-accepted security practices are applied to the Federation’s operational systems.
Good practices are followed to ensure accuracy and authenticity of metadata to enable secure and trustworthy federated transactions.
Frameworks that improve trustworthy use of Federation, such as entity categories, are implemented and adoption by Members is promoted.
Work with relevant Federation Operators to promote realization of baseline expectations.

Implementation Considerations

It is equally important to consider how these baseline expectations are to be operationalized: why, and how, should anyone believe that these expectations are met in almost all federated transactions? Is it important to know, fairly promptly, when any of those expectations no longer hold, or is it enough to know that the process by which partners become active in Federation ensures that those expectations are valid? What keeps them on track? This is addressed in companion documents [BEPractice] to be referenced here upon their acceptance by the InCommon Federation.

Appendices

Appendix A: References

[SIRTFI] REFEDS Security Incident Response Trust Framework for Federated Identity. https://refeds.org/sirtfi.

[BEPractice] Baseline Expectations Implementation Guide. http://doi.org/10.26869/TI.137.1.

[Metadata] SAML 2.0 Metadata Guide.
https://www.oasis-open.org/committees/download.php/51890/SAML%20MD%20simplified%20overview.pdf
https://www.oasis-open.org/committees/download.php/56786/sstc-saml-metadata-errata-2.0-wd-05-diff.pdf
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html (see [SDP-MD12])

Appendix B: Change Log for this Document

Changes in version 2, TI.34.3:

Renaming AAC to CTAB – The Attribute Assurance Committee (AAC) has been renamed Community Trust and Assurance Board (CTAB). All prior references to AAC have been changed to CTAB.

Formatting Baseline Expectations Statements – Updated numbering to the Baseline Expectations Statements to make referencing each statement easier across all documents.

Introduction – revised phrasing to improve readability

Paragraph 1.3 – IdP needs to conform to SIRTFI framework; reiterates IdP requirement to encrypt endpoints

Paragraph 1.5 – IdP must register errorURL.

Paragraph 2.3 – SP must conform to the SIRTFI framework; all SP endpoints must be encrypted.

Paragraph 3.3 – Federation Operator must support SIRTFI.

These are links to documents and resources related to Baseline Expectations for Trust in Federation.