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. |
This graphical roadmap shows the key players and processes involved in the implementation of Baseline Expectations 1. Below the graphic are descriptions of each of its elements. As the specific delivery dates of the various tasks are firmed up, this roadmap will be updated accordingly.
The Roadmap below was last updated September 25, 2018.
Items with an * indicate ongoing processes
IT leadership and Identity and Access Management staff involved with InCommon should become familiar with Baseline Expectations and how they can participate in and benefit from Baseline Processes. Here are some links to background information.
This would be a very good time for each Participant to verify that their InCommon Executive Contact and Site Administrators are accurately registered with InCommon. Please refer to the InCommon Roles page for details and links to forms to use for making changes. If you are a site administrator, you can use the Federation Manager to do the verification.
The InCommon Participation Agreement (PA) has always contained statements expressing expectations of Participants very similar to Baseline Expectations. It is being revised to specifically reference the Baseline Expectations above, and to remove reference to Participant Operating Practices (POP), which will no longer be required. The new PA will go into effect at the end of a 90-day formal notification period. There is nothing Participants need do in response.
InCommon Operations will start sending the results of a "health check" of all entities belonging to a Participant to the Site Admins, including items that figure specifically in Baseline Expectations, such as working contact addresses and metadata supporting a positive user experience ("MDUI information"), as well as some informational items, such as endpoints that are not protected with HTTPS. The notification will ask Site Admins to make needed corrections by an identified date, or to communicate a plan that includes a reasonable time frame. The CTAB will engage Participants on reasonable ways to address these common needs in a common way.
Participants can ask questions about specific operational practices in relation to Baseline Expectations in a forum to be provided and facilitated by the CTAB. For example, "I do X, Y, and Z to maintain the security of my Service Provider (SP) or Identity Provider (IdP) - does that meet the expectation of generally accepted security practices"?
A user or staff member associated with a Participant who believes another Participant's entity does not meet Baseline Expectations can use this process to resolve the matter. For example, someone operating an SP at Participant X who believes that Participant Y's IdP does not properly perform R&S attribute release yet it is tagged with the R&S entity category can enlist InCommon's process to address the matter.
The CTAB will play a key role in the Community Consensus and Dispute Resolution Processes.
This is a big change from what the CTAB was originally intended to do, which calls for a charter update and revised membership model.
The CTAB will think through the "rules of the road" for facilitating the Community Consensus Process, keeping the Participant community involved and informed.
Most entities' metadata lacks a privacy policy URL and has an insufficient set of MDUI Information. The CTAB will prepare advice on how to reasonably address each of these needs. This may include a template privacy policy for an IdP and another for an SP. The Acceptable Use Policy at some organizations may also suffice for these purposes. These specific needs can be used to inaugurate the Community Consensus Process.
The CTAB will be prepared to engage in this process, which can only start after InCommon Support has created the supporting workflow.
As the statutory governing body for the InCommon Federation, the Steering Committee accepts and approves the CTAB's new charter and membership, and approves the revised Participation Agreement and the Federation Operating Policies and Practices.
The Community Dispute Resolution Process aims to produce a resolution that is acceptable to concerned parties and tracks implementation of the agreed mitigation. When that fails, the CTAB recommends a resolution in the form of alteration or removal of the concerned entity's metadata to the Steering Committee, which reviews and authorizes that action or recommend an alternate course. An authorized resolution is then implemented by InCommon, following the Process to Notify InCommon Community of Intent to Alter Participant Metadata.
InCommon will build tools to help Participants keep their entity metadata in good shape, publish Baseline Processes-related information, and actively support several Baseline Processes.
This is the technology that goes through all entity metadata and provides detailed info on items that need something done to bring them up to Baseline Expectations. It also provides other informational feedback as convenient. It is made available by one or more of several means, starting with a wiki or web site accessible to InCommon users and eventually providing information with which to enhance a dashboard in the Federation Manager (FM).
Health check info is broken out by Participant and emailed to their Site Admins. Notification is repeated once more as necessary. If a Site Admin has not addressed issues identified by the health check, or notified InCommon of their plan to complete that task within a reasonable interval after notification, place on an escalation list. InCommon Management handles by escalating to Executive Contact if known, and/or to CIO.
To keep the operation of Baseline Processes utterly transparent, create a website, set of wiki pages, monthly newsletter, or other media in which to report on actions taken by Baseline Processes and other Baseline Expectations-related information. Think through who does what when and define any associated workflows, ticket schema, etc.
This will provide each Site Admin with a view of the health of each of their entities, improving their ability to recognize when one has some issue to be addressed.
The purpose of all of these Baseline Processes is to provide all the help and reasonable opportunity for a Participant to correct an issue with one of their entities. But should all such measures fail, the last resort is for InCommon to unilaterally alter or remove the entity appropriately. This is undertaken on approval of the InCommon Steering Committee, and before actually doing so the entire Participant community is notified, essentially to ask if someone can help the Participant avoid this action. The workflow supporting these final steps must be defined.
The Community Dispute Resolution Process has several stages and can require a fair amount of recording of detailed information comprising the CTAB's Docket, passing that to associated parties, including the CTAB, and ultimately reporting a suitable digest of that information on the BE Website.
When Baseline Processes reach the point that InCommon will take unilateral action to alter or remove an entity's metadata, it is important either to be able to prevent its (presumably accidental) reinstatement to federation metadata until it has been checked, or to quickly become aware that that has happened so that InCommon can manage the situation.
Define the workflow for receiving, reviewing, and acting on requests from Participants to reinstate an entity that was altered or removed from InCommon metadata.
The Participant Agreement (PA) and Federation Operating Policies and Practices documents will be modified to properly reflect the role of Baseline Expectations and Processes within the InCommon Federation. Proposed revisions pass Internet2 Legal review and must be accepted by the InCommon Steering Committee on behalf of the Participant community. Per the existing PA, the new PA takes effect only after a 90-day notification period is completed.
Each month, InCommon operations will publish reports that highlight Participants that meet or do not meet the baseline expectations.