Community Dispute Resolution Process
This document is curated under the Internet2 Trust and Identity Document Stewardship program. Download the official text from the Internet2 Trust and Identity Document Repository at: http://doi.org/10.26869/TI.118.1
Document Date: December 2018
The Community Dispute Resolution process is used to address concerns that may arise about some aspect of an entity’s operation from the perspective of meeting Baseline Expectations for Trust in Federation. This process is one means of fulfilling the requirements of the Dispute Resolution Procedure defined in Section 8 of the InCommon Federation Operating Policies and Practices (FOPP). Any party with a stake in the trustworthiness of an entity in InCommon may use this process to address their concern; in particular, they do not need to represent an InCommon participant.
Dispute resolution proceeds by stages, using an informal and lightweight method at first, and progressing to further formality and rigor only if needed.
First stage – Direct contact between participants
When a concerned party believes they have noticed something about a participant’s operation that may not meet Baseline Expectations for Trust in Federation, they should use published contact information to try to resolve the concern with the participant informally and directly. InCommon need not be made aware of the concern or its successful resolution.
Second stage – involving InCommon staff
If the first stage does not produce a successful resolution, the concerned party may elect to contact InCommon at firstname.lastname@example.org to express their concern and request that InCommon addresses the matter with the participant. In this case:
- InCommon staff makes an initial determination if the concern should be treated as a security incident, in which case the InCommon Security Incident Response Team will be notified and the matter will be tracked according to that process.
- Otherwise, if this is not a security incident, InCommon staff contacts the participant as a matter of customer service to confirm the concern and see if some information or other assistance can help to resolve the matter.
- If the resolution of the matter is necessary for the Participant to meet Baseline Expectations, InCommon staff also inform the participant that resolving the matter is their obligation under their InCommon Participation Agreement.
- If the participant agrees to resolve it in a reasonable time frame, InCommon staff updates the concerned party with this information and periodically checks with the participant to track their progress, and this process concludes.
- If a resolution is not found by this means, InCommon staff:
- Create a private docket entry – a confidential file only shared among InCommon staff and Community Trust and Assurance Board (CTAB) members – containing details such as the description of concern, dates, concerned parties and their contact info.
- Create a public docket entry for the matter – a publicly accessible file – containing information on the nature of the concern and dates of onset of Second and Third Stages but that does not identify the participant or concerned party.
- Escalate the matter to the third stage, notifying the concerned party of this change in status.
Third stage – involving CTAB
Moving to the third stage will occur if the efforts outlined in the first stage and second stage do not result in a resolution.
- InCommon staff notify CTAB of the concern and provide the private docket entry.
- CTAB notifies participant of its intent to formally review the matter on behalf of the InCommon community. This notification will:
- Describe what is expected of the participant and of the review process, and
- Request a reply that explains either
- Why the matter does not contradict participant’s obligations under the Participation Agreement, or
- A plan to satisfactorily mitigate the concern.
- If the Participant agrees to a reasonable remediation plan and time frame, CTAB asks InCommon staff to:
- Update the public and private docket entries accordingly,
- Periodically check with the Participant to track their progress, and
- Notify the concerned party accordingly.
- This process concludes if the remediation, or a mutually agreeable update to it, is completed in the agreed time frame.
- If the agreed remediation is not completed in the agreed time frame:
- InCommon staff notifies CTAB of the lack of agreed implementation,
- InCommon staff updates the public and private docket entries to reflect this status,
- The matter is referred by CTAB to InCommon Steering with a recommendation to remove the concerned entity or entity attribute(s) from federation metadata until such time as the participant demonstrates implementation of a mitigation as agreed by CTAB, and
- InCommon staff notifies the concerned party and participant of this recommendation.
- If the InCommon Steering Committee accepts CTAB’s recommendation, the Process to Notify InCommon Community of Intent to Alter Participant Metadata is followed.
- If the InCommon Steering Committee doesn’t accept the recommendation,
- InCommon staff records the reason in the private and public docket entries and
- InCommon staff notifies participant and concerned party about the final disposition.