Page tree
Skip to end of metadata
Go to start of metadata

This graphical roadmap shows the key players and processes involved in the implementation of Baseline Expectations. 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 

Sep2017OctNovDecJan2018FebMarAprMayJunJulAugSepOctNovDecPolicy/Legal CompleteBE in EffectFinal Date AnnouncedBE Deadline
Participants
CTAB
Steering
InCommon

Read new Participation Agreement

Improve entity metadata

Review Baseline Expectations and Processes

Act on Site Admin feedback info *

Use Community Consensus Process *

Use Community Dispute Resolution Process *

Prepare Privacy URL and MDUI advice

Revise AAC charter to CTAB

Refresh CTAB membership

Community Consensus Process *

Community Dispute Resolution Process *

Community Consensus Process Consultation

Accept CTAB charter

Accept CTAB members

Notification of Processes

Authorize dispute resolutions *

Accept PA and FOPP

Develop entity health check & Site Admin feedback loop

Send entity health checks to site admins monthly *

Meeting BE option in FM

Reinstatement control

Create BE website

Support Community Dispute Resolution Process *

Reinstatement workflow

Revise PA and FOPP

Notify Participants of new PA

Publish orgs meeting and not meeting BE *

Workflow of Process of Intent to Alter

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.

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

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.

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 Operations

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.

Reinstatement Controls

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.

Reinstatement Workflow

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.


  • No labels