When a new identity federation applies to join eduGAIN, the eduGAIN Secretariat and business development team will work closely with them to help them prepare and meet all the membership requirements. The following steps will be taken and will be used as a template to manage Candidate applications. Each "step" may run concurrently, depending the on the readiness of the federation.
| Candidate Name | Federation X |
|---|---|
| OTRS Ticket Number | TT#2022012134009266 |
eduGAIN New Candidate Process
| Steps | Requirements | Actions | Owner | Timeframe | Notes |
|---|---|---|---|---|---|
| Step 1: Initial application meeting / readiness discussion | This initial meeting will talk the candidate through the joining process, get an understanding of the technical infrastructure of the federation and it's maturity and also share information about useful resources for the federation such as the eduGAIN website and wiki and the REFEDS resources. If not already familiar, federations will also be talked through the available document templates and the various eduGAIN tools that can be used for testing compliance and reviewing issues. |
| BD Sec | Set up meeting within 2 weeks of receiving request | |
| Step 2: Collect required information for membership application | There are a number of formalities that need to be addressed before a federation can become a membership candidate. These are known as the "joining checklist" and represent the core information that is held about each federation to enable metadata consumption and to start the trust building process. |
| Sec / OT | TBD - depending on maturity of federation | |
Step 3: eduGAIN Secretariat review of federation documentation | The eduGAIN Secretariat will undertake an initial review of the federation Policy and MRPS documents and may invite others to help support this process. The aim of this step is to help the federation identify any potential issues that might come up from the community review process and ensure step 5 goes as smoothly as possible. |
| Sec | 4 - 6 weeks | |
| Step 4: Technical review | The purpose of the technical review is to iron out any issues the federation may have with publishing and consuming eduGAIN metadata on a daily basis to ensure that the federation can run successfully with no / low error rate when membership is approved. |
| Sec / OT | 8 weeks (concurrent with other tasks) | |
| Step 5: membership review of federation documentation | As stated in the eduGAIN Constitution, the eduGAIN Steering Group (eSG) is responsible for: "Reviewing and approving the membership of new Federations". Step 5 and Step 6 support this requirement. |
| Sec | 4 weeks (or 2-3 weeks for assessment + 1-2 weeks for the applicant to process the feedback?) | |
| Step 6: voting | Formalised vote for membership acceptance |
| Sec | 2 weeks | |
| Step 7: formal registration | This final step ensures that the candidate is able to fully utilise the eduGAIN service after the community vote is successful. |
| Sec |
eduGAIN New Candidate Assessment Feedback
Assessment Period: 26 July 2022 - 23 August 2022
| Comment # | Document (Policy / MRPS) | Document line / reference | Proposed Change or Query | Proposer / Affiliation | Action / decision (to be filled in by candidate) |
|---|---|---|---|---|---|
| 1 | Policy | 6.3 | It is not clear who the juristic person of record is or which court has jurisdiction. Reading between the lines, it seems as if this is the Ubuntnet Alliance and thus the Republic of Malawi. It would be useful if 6.3 recorded this unambiguously. (Particularly given section 3 of the MRPS references a contractual relationship with this entity.) | Guy / SAFIRE | This is captured in Section 3 of the policy, but now also made explicit in 6.3 |
| 2 | Policy | 4 | The eligibility criteria for IdPs are very broad and effectively include all countries in the world. It might make sense to limit it to entities with a legal presence in any country in Africa. (Conversely, I would not want to limit SP eligibility in the same way.) | Guy / SAFIRE | Policy document updated with more specificity. |
| 3 | MRPS | 4 | The example registrationAuthority should be updated to reflect the one that will actually be used. | Guy / SAFIRE | This has been fixed in the MRPS |
| 4 | MRPS | references | There's a URL showing as https://www.[AFRICAN-CATCH-ALL]/... which points to the eduID.ng policy. | Guy / SAFIRE | The MRPS reference issue has been fixed |
| 5 | MRPS | links | A number of what appear to be OCR-type "typos" in some of the links in the MPRS, example: bttps-//www edujd afrjca/seryjce-pmyjders | Nicole / InCommon | We are unable to locate the specific issue, but we have updated and validated the document again on this. |
| 6 | Policy | line 256 | The MRPS states that "changes need to be approved by the Governing Body" but the document does not define such a body, only that governance is delegated to the three RRENs. | Alex Stuart / UK federation | The delegation to the three RRENs as “Governing Body" is a management feature to meet the requirements. This “Governing Body” is legally served by Ubuntunet Alliance as per policy statement. |
| 7 | MRPS | line 115 | "A member's canonical name matches registrant information shown in DNS" presumably through WHOIS and not DNS | Alex Stuart / UK federation | Ultimately, the registrant information is in DNS. We have added a line: "This information will be retrieved using the WHOIS query tool." |
| 8 | MRPS and metadata | MRPS line 137 and entityID http://drive.ubuntunet.net/apps/user_saml/saml/metadata | The MRPS says that the federation operator will ensure "protocol endpoints are properly protected with TLS / SSL certificates". However, the UA NextCloud Storage Service SP has endpoints that are pan HTTP. The eduid.africa metadata toolchain should consider this an ERROR. | Alex Stuart / UK federation | Entity has been fixed and metadata updated accordingly. |