The content on this page reflects the work of Baseline Expectations 1 in 2018/19. It is preserved for historical reference only. For the latest on Baseline Expectations, please visit the Baseline Expectations wiki home page. |
The background, philosophy, and strategic direction of the program are in the document, "Baseline Expectations for Trust in Federation: Increasing Trust and Interoperability in InCommon."
The InCommon Steering Committee reviewed the terms and conditions of the Federation Operating Policies and Practices (“FOPP”) and the InCommon Participation Agreement (the “Participation Agreement”) to determine what changes were necessary. The InCommon Steering Committee determined, through discussions with the Participant community, that in addition to referencing the Baseline Expectations in the documents, the Dispute Resolution process should also be changed, in order to more effectively resolve disputes among Participants and to better allow the Baseline Expectations to be enforced. The revised FOPP and Participation Agreement, which may be found on the InCommon website, include the full range of changes necessary to accommodate the Baseline Expectations. You can see the notice sent to Executive Contacts and Billing Contacts, which includes a list of changes, in this PDF.
Yes. If it is registered in the InCommon metadata, then Baseline Expectations apply.
The community is not on a "gotcha" campaign to catch those not meeting the Baseline Expectations. That said, all organizations are expected to take action in a reasonable amount of time. There is a community dispute resolution process under development for use in cases when an organization does not meet the Baseline Expectations.
We have had a lot of questions about privacy policies and whether there are examples. Most organizations have an existing privacy policy for how user data will be handled. We encourage you to point at an existing policy with the privacy URL, rather than create a new policy.
SIRTFI (Security Incident Response Trust Framework for Federated Identity) is an international framework that enables coordination of incident response across federated organizations. While adopting the SIRTFI framework is not a requirement of Baseline Expectations, it is a very good way of meeting the "generally accepted security practices" Baseline requirement. Also, including a security contact in metadata is a requirement. InCommon supports the SIRTFI framework and encourages all participants to adopt the framework and self-assert that fact via the Federation Manager.
Baseline Expectations calls out the following expectations of the Federation Operator. How we are meeting the requirement is listed immediately below each item.
Required elements include three types of contacts (technical, admin, and security), MDUI (Metadata User Interface) information, and a URL pointing to a privacy policy. These are listed in the Baseline Expectations foundational document. In addition, we recommend including an error URL to provide a landing page for users to determine where to get help. InCommon has published a high-level document, "Baseline Expectations for InCommon Execs," that provides a description and purpose of each required and recommended element.
There are no specific requirements for endpoints as part of the Baseline Expectations. However, InCommon Operations has requirements and recommendations for endpoints documented in the wiki, https://spaces.at.internet2.edu/x/IImKAQ
You should not need to understand XML syntax for this purpose. An InCommon site administrator can edit and update metadata using the Federation Manager web interface. Information about each element in metadata, including those that are part of Baseline Expectations, is also available on the wiki.
The logo significantly improves the user experience. When accessing a federated service, typically the user is presented with an Identity Provider discovery page. Having logos associated with each organization name makes for much faster scanning, so the user can pick out the appropriate organization quickly and continue with the sign-in process. This shows how a service provider's DisplayName, Description, and Logo appear on an IdP login screen:
Also, having a logo present in Service Provider metadata allows user consent information screens at Identity Providers to show the user a logo for the service to which they are asked to release information.
You can see more-detailed guidance and other screenshots demonstrating the use of logos, on this blog.
It is the responsibility of the organization submitting SP metadata to maintain that metadata according to Baseline Expectations. If you have concerns about a service you run that is not complying with Baseline Expectations, please ask that organization to correct its SP metadata according to the documentation on the wiki. If you run an SP that is hosted at your organization, and you (or a delegated administrator at your organization) submit the metadata for that SP, you are responsible for maintaining that metadata according to Baseline Expectations. Please consider the use cases noted in the previous FAQ answer when choosing elements such as logos. You want to choose a logo that tells the user something about the service they are accessing.
InCommon Operations has developed a process for alerting site admins and execs about the status of their metadata as it relates to the Baseline Expectations. InCommon Ops checks your metadata for the required elements and generates a report with the status of each element – a health check. InCommon will send email periodically with the results of the health check for your metadata.
Short answer:
Long answer:
Yes, all metadata registered by InCommon must meet Baseline Expectations. You can meet baseline expectations in InCommon metadata without having to modify the metadata of your SAML software. InCommon Site Administrators may update their organization's metadata via the InCommon Federation Manager.
Yes, all metadata registered by InCommon must meet Baseline Expectations. Hide from discovery does not opt your IdP out of the federation, it simply adds an entity attribute to metadata that must still meet baseline expectations. InCommon Site Administrators may update their organization's metadata via the InCommon Federation Manager.
Yes, documentation is available in Metadata Administration.
I am concerned that altering my metadata to meet baseline expectations will break downstream processes, how can I be certain that meeting baseline expectations will not break things?
Everything specified as required by baseline expectations in metadata is already in widespread use across not only InCommon, but over 50 other national research and education federations. The use of the required elements has over ten years of real-world use. Software which conforms with the OASIS Committee Specification, SAML V2.0 Metadata Interoperability Profile Version 1.0, August 2009 and the OASIS Committee Specification, Identity Provider Discovery Service Protocol and Profile, March 2008 will not break. All software deployed in InCommon and other federations by definition should already be able to meet these requirements.
Is there a way for an organization to bulk update its metadata to meet Baseline Expectations?
Yes, your InCommon Site Administrator(s) can use our new Baseline Expectations Bulk Update tool to update the following fields in all your entity descriptors which do not already contain the elements:
You cannot use this tool to update mdui:DisplayName, since that field should be different for each entity descriptor. This tool only allows adding missing elements, it does not allow you to change existing elements in metadata. For more information, visit the documentation for this feature.