eduGAIN as it currently exists is based on SAML, which imposed a number of limitations to how the topology of eduGIAN is set up. Furthermore, R&E federations have build over 20+ years of expertise in running identity federation at scale, which has led to the adoption of various technical and operation practices. OpenID Federation (OIDFed) provides multiple ways of designing the federation topology, which in turn also impose limitations.
The eduGAIN OIDFed group has been discussing multiple scenarios in which an OIDFed based eduGAIN federation could be set up. As we currently have no operation expertise, it is hard to decide which of the scenarios (or perhaps even a combination of scenarios) is the most feasible.
This document lists the (high level) requirements that have been brought up, as well as the scenarios discussed so far. It is the intent to implement (as much as possible) the various scenarios in a PoC or pilot setting, and then evaluate these against the requirements.
Requirements
The following requirements were discussed. This task is not about redefining eduGAIn policy, however, in many cases the (existing) eduGAIN policy will require certain capabilities form the trust infrastructure.
To indicate where we are representing eduGAIN policy, the text is presented in italic
| ID | Name | Description | MOSCOW |
|---|---|---|---|
| 1 | KISS | OIDFed allows for many different patterns and typologies. All things equal, we prefer the simplest solution. We recognize we should try to make the technical burden for OPs and RPs as low as possible, perhaps even at the cost of an increase in work for federation operators. | M |
| 2 | Trust infrastructure for Cross border personal data exchange | The purpose of eduGAIN is to provide a trust infrastructure to allow for cross border exchange of natural persons personal data for the purpose of interacting with services in the global R&E sector. The information that gets transported, and how, is out of scope. We will refrain from making transport protocol specific choices, unless there is absolutely no way to avoid it. | M |
| 3 | Trust infrastructure for National personal data exchange | eduGAIN is build on top of national (identity) federations. While not mandatory, it seems like a good idea to make Subordinate federations and eduGAIN work in (very) similar ways. In the existing SAML based deployment, we have suffered gravely from the differences between national federations. By making sure eduGAIN and the Subordinate federations share a common operational model and concepts we will increase transparency and understanding and may more easily share operational expertise and technical solutions. | S |
| 4 | eduGAIN Stakeholders | Learners, teachers, researchers and staff; OPs (typically institutions), RPs, research communities and university alliances, all are equal stakeholders in the trust infrastructure. We seek to provide an infrastructure that meets the combined needs of all of these stakeholders, satisfies their (legal) rights and allows them to benefit from the infrastructure in an equal way, within the propose of their interaction with the infrastructure. | M |
| 5 | eduGAIN as an Inter-federation | eduGAIN is an inter-federation and as such depends on Subordinate federations to determine eligibility for joining the Subordinate federation, in accordance with local policies. eduGAIN will only enroll Intermediate Authorities, and may enroll Trust Mark Owners and Trust Mark Issuers. | M |
| 6 | eduGAIN Policy | While Subordinate federation policies regulate eligibility for a Leaf joining the national federation, eduGAIN may impose additional technical or organizational requirements for Leafs to become eligible to join eduGAIN. The trust infrastructure must support this capability | M |
| 7 | eduGAIN Autonomy | eduGAIN may independently (so without the need to contact the Subordinate federation) decide to refuse, restrict, block or remove a Leaf from eduGAIN if it believes it is in violation of the eduGAIN policy. The trust infrastructure must support this capability | M |
| 8 | Subordinate federation Autonomy | A Subordinate federation should be able to exclude specific Leafs from being part of eduGAIN, while still being members of the Subordinate federation. The fact that the Subordinate federation is an Intermediate Authority in eduGAIN does not automatically lead to the inclusion of all Leafs in the Subordinate federation. The trust infrastructure must support this capability | M |
| 9 | Enforce Subordinate federation Autonomy | It should not be possible for Leafs to circumvent requirement (8) by either erroneous or perhaps malicious behavior on the side of the Leaf | S |
| 10 | No Leaf duplication | A Leaf should not able join multiple Subordinate federations | Impact? |
| 11 | Any TA or IA must have a Resolver | Resolvers are a cornerstone to lifting the burden of Trustchain evaluation for Leafs. The trust infrastructure must support this capability | M |
| 12 | Resolvers are cache | The TA and IA Entities in the ecosystem are authoritative. A Resolver which is part of the TA or IA (as listed in the TA/IA Entity Configuration) is not ever independently making decisions wrt the Trustchain evaluation, it is just a "dumb" cache. Put differently: Any Trustchain evaluate by a Resolver must always yield the same result as when the Trustchain would have been build directly against the TA or IA the Resolver is part of. | M |