eduGAIN as it currently exists is based on SAML, which imposed a number of limitations to how the topology of eduGIAN eduGAIN 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.
...
The following requirements were discussed. As th the 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 |
|---|
| Why? | MOSCOW | Comments | ||
|---|---|---|---|---|
| 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 | not sure this is relevant for the discussion? this is a top level strategy discussion not a OID specific discussion |
| 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 | rephrase as an OID requirement |
| 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 | I'll put this here, but it somehow covers also 10,11 and 12. A major benefit from oidfed is the hierarchical nature of the trust chain. In order to make good use of that feature we should allow for further subordinates below the federations, I would add that as a requirement. Moreover, subordinates of subordinates must have a registration policy. |
| 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 (12) 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 | |
| 14 | No Leaf duplication | The same Leaf should not able join multiple Subordinate federations | Impact? | Is this really needed? Current eduGAIN has not such requirement and we have (not perfect) priorities rules to avoid clashes. |
| 15 | Any TA |
| must have a Resolver | Resolvers are a cornerstone to lifting the burden of |
| Trust Chain 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 |
| Trust Chain evaluation, it is just a "dumb" cache. Put differently: Any |
| Trust Chain evaluate by a Resolver must always yield the same result as when the |
| Trust Chain would have been build directly against the TA or IA the Resolver is part of. | M | |||
| 17 | Test federations | Can we have "test" federations in an operationally convenient way (both for FedOps, OP and RP perspective) | S |
Strategies for implementing policy
OpenID Federation provides a number of elements which can be used to describe the trust properties of Entities. These include the Entity Configuration, Subordinate statements and Trust Marks. Core assumption of the OpenID federation Sspecification is that evaluation of these statements by a Trust Anchor results in a description of the trust between an Entity, potentially Intermediates, and the TA, as expressed in the Trust Chain. The Trust Anchor may publicly express policies which they apply on their Subordinates in the form of Federation Policy.
While all of the aforementioned elements are publicly discoverable via Entity Configuration or by querying the available APIs, there are also several policy aspects that are not defined in the specification, yet still may be used to influence the policy within the federation:
- Federation membership eligibility: the criteria that define if and how Entities (or better: the organization operating such Entities) are eligible to become members of a given federation are out of scope. Typically eligibility is a mix between technical requirements (some of which may likely be present in Entity Configuration, at least in part), and organizational rules (e.g. "Must be an educational institution as indicated by the Ministry of Education"), some of which might be expressed in Entity Configuration also, e.g. by the use of Trust Marks. It is however equally feasible the TA has some additional "internal" rules it uses when assessing eligibility.
- Trust Mark eligibility: It is the Trust Mark Issuer which decides the eligibility criteria for its Trust Marks. Again the eligibility criteria may be internally sourced.
- No right to service: While a TA may be capable of building a trust chain, it is not mandated to do so for everyone who asks for it. The specification already suggests authentication mechanisms which could be required, but more generally also other authorization might be in place. (e.g. IP based). The same limitation also applies for trust Mark Issuers and Trust Mark Owners.
- Federation hierarchy: The hierarchy of the federation may be such that certain Trust Paths cannot be walked at all.
As part of the OIDFed eduGAIN pilot we wish to further explore the following scenarios, to be evaluated against the above requirements (if relevent):
- Using Trust Marks as an indication of federation membership for eduGAIN and optionally national federations
- Federation policy as a means to enforce certain properties on Subordinates
- Federation hierarchy as a means to deny certain subordinates the ability to participate in eduGAIN (while still participating in the national federation), for example fro test federation