...
The following requirements were discussed. This As th task is not about redefining eduGAIn eduGAIN policy, however, in many cases the (existing) eduGAIN policy will require certain capabilities form the trust infrastructure.
To indicate where we are describing 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 trustworthy (cross border) exchange of natural persons personal data for the purpose of interacting with services in the global R&E sector. | M |
| 3 | eduGAIN Stakeholders | Learners, teachers, researchers and staff; Institutions, Services, 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 (legitimate) propose of their interactions with the ecosystem. | M |
| 4 | Secure | The trust infrastructure design must be inherently secure to implement and operate. | M |
| 5 | Scalable | The trust infrastructure design must be inherently scalable and should for example avoid SPOFs | M |
| 6 | Transport Protocol independence | The information that gets transported, and how, is out of scope. |
We For the 'core' capabilities of the trust infrastructure, 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| 8 | Trust infrastructure for Cross sector personal data exchange | The R&E sector collaborates abundantly with other sectors (e.g. Gov, Healthcare, private sector) in society. The trust framework should not introduce unneeded barriers to limit these collaborations. | S |
| 9 | eduGAIN as an Inter-federation | eduGAIN is an inter-federation and as such depends on Subordinate federations to determine Leaf 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| 10 | 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| 11 | 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| 12 | 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| 13 | Enforce Subordinate federation Autonomy | It should not be possible for Leafs to circumvent requirement ( |
812) by either erroneous or perhaps malicious behavior on the side of the Leaf
Would probably be good to describe the "attack vector" here for a given scenario, so we understand what we are trying to prevent | S |
10A | The same Leaf should not able join multiple Subordinate federations | Impact? |
11| 15 | 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| 16 | 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 will 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 |
