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.
Note | ||
---|---|---|
| ||
InCommon Operations will provide a “platform” that makes it easy for me as an InCommon member to manage trust relationships with international partners. (Scott Koranda) |
Requirement Set A
- I want to know InCommon and the UK have had some type of formal discussion.
- I want to know there is a document (MOU?) that explains the agreement between the two federations and where I can read that document.
- 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.
- 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.
- 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
- InCommon currently publishes a metadata file containing ONLY entities which are members of IC.
- 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.
- These files are not specific to individual IC members, but rather are available to all and are constructed using specific rules and criteria.
- Individual entities managing IDPs and SPs are responsible for choosing which of these files, if any, they want to load and use.
- In addition, individual entities could choose to remove some of the entities from these files, based on local criteria and rules.
- InCommon should provide a file for import into eduGAIN, if relevant policy and practice issues are addressed.
- 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.
- 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"").
- 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.
- 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.