The community consultation on a second set of Baseline Expectations, including three technical requirements aimed at improving security and the user experience concluded on October 10, 2020. The final set of requirements will be presented to the InCommon Steering Committee for formal approval in November 2020.

Schedule

Participate

Visit the Baseline Expectations 2 Consultation page to review the documents under consultation and to provide your feedback.

Wednesday, September 23, 2020

View the recorded session on YouTube

Invitation

Dear InCommon Participants:

The InCommon Community Trust and Assurance Board (CTAB) has opened a consultation on a InCommon Steering Committee has approved the second set of Baseline Expectations, including three technical requirements aimed at improving security and the user experience.  Please review these expectations and take this opportunity to provide feedback. CTAB invites your input through October 19, 2020 prior to finalizing these requirementsThis follows an extensive community collaboration and consultation process.

The InCommon community adopted Baseline Expectations for Trust in Federation in 2018, including a set of common expectations that all participants must meet. The effort concluded successfully in February 2019, when 100 percent of Federation participants met those expectations.

Baseline Expectations 2 (BE2) proposes includes three additional elements that all participants must meet by during 2021.

1. Each Identity Provider and Service Provider will secure its connection endpoints with current and trusted encryption (TLS)
2. All Identity Providers and Service Providers will comply with the SIRTFI international security response framework
3. All Identity Providers will include an error URL in metadata

We will hold a community presentation and discussion on Wednesday, September 23 to provide a summary and answer questions about BE2. Details and Zoom coordinates are below.

The Baseline Expectations have improved the interoperability and security of the InCommon Federation, and these three additional elements are the next logical progression. Thank you for your support of Baseline and helping the community reach 100% adherence to these, just as we did during the first round.

Sincerely,

STATEMENT: All Identity Providers (IdP) and Service Providers (SP) service endpoints must be secured with current and community-trusted transport layer encryption. 

When registering an entity (IdP or SP) in InCommon, all connection endpoints of that entity must be an https URL. The applied transport layer security protocol and associated cipher must be current and trusted by the community. 

Popular security testing software such as the Qualys SSL Lab Server test offers a convenient way to test your server against these criteria and identify weaknesses. If using the Qualys SSL Lab Server test, an overall rating of A or better is considered meeting the requirements of the InCommon Baseline Expectations.

MORE: Clarification - Encrypt Entity Service Endpoints

STATEMENT: All entities (IdP and SP) meet the requirements of the Sirtfi v1.0 trust framework when handling security incidents involving federation participants

The Sirtfi trust framework v1.0 enables standardized and timely security incident response coordination among federation participants. When signaling and responding to security incidents within the federation, entity operators shall adhere to the process defined in the Sirtfi framework.

MORE: Clarification - Entity Complies with Sirtfi v1.0

STATEMENT: All IdP metadata must include an errorURL; if the condition is appropriate, SPs should use the IdP-supplied errorURL to direct the user to proper support.

IdP entity metadata must include a valid errorURL in its IDPSSODescriptor element.

An errorURL specifies a location to direct a user for problem resolution and additional support in the event a user encounters problems accessing a service. In SAML metadata for an IdP, errorURL is an XML attribute applied to the IDPSSODescriptor element. 

When a service provider is unable to process an authentication assertion from an IdP, it may display within its error message a link to this URL to direct the user back to the IdP for additional assistance.  

MORE: Clarification - IDP Metadata Must Have an Error URL

Schedule