The Canonical Interfederation Use Case

This document is a premature generalization of what we might call the canonical interfederation use case gleaned from a recent thread on the interfed mailing list.

Requirement Set A

1. I want to know InCommon and the UK have had some type of formal discussion.
2. I want to know there is a document (MOU?) that explains the agreement between the two federations and where I can read that document.
3. I want to know that the entities that the UK "passes along" to InCommon and that InCommon makes available as a feed to me are entities that are in "good standing" in the UK federation.
4. If InCommon and the UK can agree on categories like R&S and what they mean, I want to know if entities in the UK are part of those categories.
5. If InCommon and the UK can agree on LOA and what they mean, I want to know if entities in the UK are part of a particular LOA.

Observation Set A

• Requirements 1 and 2 above are a good, high-level description of the policy-related requirements of this use case.
• From InCommon’s point of view, requirement 3 is completely out of scope (Scott K: I would like to understand why? If it may be possible, and I argue should be, addressed as part of the MOU then I don't see how it can be completely out of scope?). However, it may be possible to address this issue in the MOU referenced in requirement 2.
• Requirements 4 and 5 are REFEDs-level issues. In fact, both are current REFEDs work items.

Requirement Set B

1. InCommon currently publishes a metadata file containing ONLY entities which are members of IC. 
2. In addition, IC should also publish "alternative" metadata files which include entities which are members of other Higher Ed/Research Federations, and entities which may not be a member of any HE Federation. IC MUST provide a description of the criteria used to construct each of these files, including any agreements with other Federations. 
3. These files are not specific to individual IC members, but rather are available to all and are constructed using specific rules and criteria.
4. Individual entities managing IDPs and SPs are responsible for choosing which of these files, if any, they want to load and use.
5. In addition, individual entities could choose to remove some of the entities from these files, based on local criteria and rules.
6. InCommon should provide a file for import into eduGAIN, if relevant policy and practice issues are addressed.
7. The Interfed group should work to develop use cases that would help IC OPS determine a set of criteria to be used for constructing "alternative" metadata files.
8. The Interfed group should work to identify issues that campuses want addressed before they use a metadata file with NON-IC members (ie the policy buried beneath Scott K's phrase " InCommon "vetted international partners"").
9. IC should encourage and facilitate work to develop international consensus around the syntax and semantics of various TAG values that are included in Federtationmetadata files.
10. The alternative metadata files should include theseTAG values.

March 2013 Driving Use Case

An InCommon SP (example: LIGO wiki) accepts authentication from both external IdPs (i.e., IdPs in other federations) and InCommon IdPs, where:

• The SP doesn't need to sign agreements with federations other than InCommon.
• The external IdP doesn't need to join InCommon.
• The SP gets all IdP metadata from InCommon.
• The IdP gets SP metadata from its local federation.
• The SP registers its metadata with InCommon and doesn't need to separately send its metadata elsewhere.
• The IdP registers its metadata with local federation.
• This use case does not disrupt other SPs that only want to accept InCommon IdPs.