...
| 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. 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. Some transport protocols may have specific implementation requirements or guidance wrt OIDFed. In such cases we will follow the protocol specific specifications which are part of the OIDfed specification as much as possible (e.g. OpenID Federation for OpenID Connect or OpenID Federation for Wallet Architectures), and draft a transport protocol specific profile. | M |
| 7 | 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 13 | Enforce Subordinate federation Autonomy | It should not be possible for Leafs to circumvent requirement (10) by either erroneous or perhaps malicious behavior on the side of the Leaf | S |
| 14 | No Leaf duplication | A The same Leaf should not able join multiple Subordinate federations | Impact? |
| 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 |
| 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) 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 |
...