Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from this space and version 2.6

Jump to: 

Table of Contents
maxLevel1
exclude(On this page)|(In this section)|(Related content)|(Get help)
typeflat
separatorpipe

Baseline Expectations 2 Progress

As of October 815, 2021:

Image RemovedImage Added



CountPercent of Total
BE2-adhering Organizations59860976%77%
BE2-adhering IdPs47548082%83%
BE2-adhering SPs4557456583%84%
IdP with Error URL509513

88%

SIRTFI-compliant IdPs48348783%84%
SIRTFI-compliant SPs45624570

83%84%


Does my organization meet Baseline Expectations?

Visit the be2-adherence-by-org page to see if your organization meets the requirements of Baseline Expectations 2.


How are we doing on endpoint encryptions?

The following graphs illustrate the participants' progress toward strengthening connection endpoints. The graphs compare the data collected across three testing cycles between April 2021 and September 2021. 

Endpoint Encryption Test Results among InCommon IdPs

Score

Apr 15, 2021

June 23, 2021

July 22,2021

Aug 26, 2021

Sept 19, 2021

A186251323

370

380
B344259221181174
C108622
F227522
n/a39

37

322721


Endpoint Encryption Test Results among InCommon SPs

ScoreApr 15, 2021June 23, 2021July 22,2021Aug 26, 2021Sept 19,2021
A32633288357437733823
B14731220120510561049
C4547443936
F23270172635
n/a800693554554514


Event Calendar

October 26, 2021 - BE2 Office Hour

Tuesday, October 26, 2021
1 PM ET | Noon CT |  10 AM PT

Zoom Link: https://internet2.zoom.us/j/99430555743

Phone (US): (669) 900-6833 
                      (646) 558-8656

Meeting ID: 994 3055 5743

Key Dates

DateMilestone
December 17, 2021Deadline to meet Baseline Expectations 2 Requirements
July 19 2021Baseline Expectations 2 becomes official policy of the InCommon Federation
November 2, 2020Baseline Expectations 2 approved by InCommon Steering Committee
November 17, 2020Implementation Kick-off, CAMP/ACAMP
January '21 - March '21CTAB begin contacting non-adhering participants

Resources

Archived Content



About Baseline Expectations 2

The second set of Baseline Expectations (BE2) adds three technical requirements aimed at improving security and the user experience. Implementation of BE2 is now under way. The InCommon Federation is expected to officially transition to BE2 on July 19, 2021.

The three BE2 elements are:

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

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