This is archived content.
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
All InCommon Participants
Review Baseline Expectations and 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.
- Baseline Expectations for Trust in Federation
- Processes to Maintain Baseline Expectations by InCommon and its Members
- IAM Online "Baseline Expectations for Trust in Federation" slides
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.
Read the New Participation Agreement
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.
Improve Entity Metadata and Act on Site Admin Feedback Info
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.
Use the Community Consensus Process
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"?
Use the Community Dispute Resolution Process
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.
Community Trust and Assurance Board
The CTAB will play a key role in the Community Consensus and Dispute Resolution Processes.
Revise Charter & Refresh Membership
This is a big change from what the CTAB was originally intended to do, which calls for a charter update and revised membership model.
Community Consensus Process
The CTAB will think through the "rules of the road" for facilitating the Community Consensus Process, keeping the Participant community involved and informed.
Prepare Privacy URL & MDUI Information Advice
Community Dispute Resolution Process
The CTAB will be prepared to engage in this process, which can only start after InCommon Support has created the supporting workflow.
InCommon Steering Committee
Accept and Approve
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.
Authorize Dispute Resolutions
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.
Develop Entity Health Check & Site Admin Feedback loop
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).
Send Entity Health Checks to Site Admins Monthly
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.
Create BE Website & Site Update Workflow
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.
Enhance Federation Manager Dashboard
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.
Workflow for Process to Notify of Intent to Alter
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.
Create Community Dispute Resolution Workflow & Support It
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.
Revise PA and FOPP and Notify Participants
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.
Publish Orgs Meeting and Not meeting Baseline Expectations
Each month, InCommon operations will publish reports that highlight Participants that meet or do not meet the baseline expectations.