Baseline Expectations FAQ
General Questions
What is the background and purpose for developing the Baseline Expectations program?
The background, philosophy, and strategic direction of the program is in the document, "Baseline Expectations for Trust in Federation: Increasing Trust and Interoperability in InCommon."
I have heard the term "Metadata Health Check." What is that?
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.
By when must I correct the issues identified in the Metadata Health Check?
Short answer: Each missing item reported in the health check contributes to poorer user experience, reduced interoperabilty, and lower trust in the InCommon Federation. So please correct them as soon as possible.
Long answer: Baseline Expectations will be formally in effect and incumbent on all InCommon Federation Participants by around the end of June 2018. After that time, issues that remain unaddressed will ultimately lead to corresponding entities being removed from the federation until they are corrected. Health check reports sent after Baseline Expectations are formally in effect will include information on how long a given entity has gone uncorrected and estimated time to its removal unless it is corrected.
Does Baseline also affect the test IdP/SP(s) that I have in metadata?
Yes. If it is in the InCommon metadata, then Baseline Expectations applies.
What happens if I don't meet Baseline Expectations?
The community is not on a "gotcha" campaign to catch those not meeting the 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 expectations.
Do you have any examples of privacy policies?
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.
What's this "SIRTFI" thing? Is that a Baseline Expectation?
SIRTFI (Security Incident Response Trust Framework for Federated Identity) is an international standard that enables coordination of incident response across federated organizations. While adopting the SIRTFI framework is not a requirement of Baseline Expectations, 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.
Metadata Questions
I have heard there are required metadata elements as part of Baseline, as well as recommended elements. Please clarify.
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.
Do the Baseline Expectations include requirements for endpoints in metadata?
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
Do you have examples of XML syntax for placing the required elements in metadata?
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, include those that are part of Baseline, is also available on the wiki.
I'm getting questions about including a logo. What is the logo used for?
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. 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 they are being asked to release information to.
SP metadata for a service that I have purchased is maintained by the organization that runs the SP. What is my responsibility?
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) submits 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.