...
| 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 |
...
| Comment # | Document (Policy / MRPS) | Document line / reference | Proposed Change or Query | Proposer / Affiliation | Action / decision (to be filled in by candidate) |
|---|---|---|---|---|---|
| 1 | Policy | 46-49 | "Exceptionally, end users are also deemed to be end users of other federations with whom AMRES makes interfederation". Is "exceptional" to signify the expectation that there will be fewer end users through interfederation than AMRES end users, or do you have a process for granting an exception? | Alex Stuart (UK federation) | End Users are both AMRES End Users and End Users of other Federations that are in interfederation with AMRES. The word "Exceptionally" has been removed to avoid confusion. |
| 2 | MRPS | 30 and 39 | Line 30 defines an entity without reference to any protocol. The restriction in line 39 to a policy of registering only SAML entities will reduce the agility of the federation if iAMRES wishes to use other protocols. I suggest that the word "SAML" is removed from line 39. | Alex Stuart (UK federation) | Good point, it has been removed. |
| 3 | MRPS | 49-43 | It is good that iAMRES explicitly includes the publishing policy regards eduGAIN. It would be better if the policy for importing entities from eduGAIN were also listed. This would provide guidance for AMRES Users, and would provide knowledge for inform interfederation partners wishing to use services from AMRES Identity Federation Users or AMRES Identity Federation Partners. | Alex Stuart (UK federation) | Added: Each entity's metadata is registered once with the iAMRES Identity Federation. Aggregated metadata of all registered entities is published by AMRES so that it can be consumed by all entities participating in iAMRES Identity Federation. iAMRES Identity Federation produces an "export metadata aggregate", published by AMRES, comprising the metadata of entities chosen to be exported to eduGAIN. The “export metadata aggregates” produced by the participating federations are all consumed by eduGAIN, which from them generates an "eduGAIN aggregate", that is made available for consumption by each participating federation. Entities from the ”eduGAIN aggregate” are checked for conformance to iAMRES Identity Federation standards and if satisfactory are re-published in the “iAMRES Identity Federation's aggregates” by AMRES, which are consumed by entities in iAMRES Identity Federation. |
| 4 | MRPS | 57-62 | This is only a subset of the namespaces that are used in eduGAIN today. I suggest that this list is removed from the MRPS and maintained on the AMRES technical website. | Alex Stuart (UK federation) | Good point, it has been removed. |
| 5 | MRPS | 77-78 | This item refers to domains in entityIDs. There is no corresponding item about AMRES verifying the scopes in metadata of Identity Providers (although this is explicitly in the eduGAIN SAML profile, which would apply to entities exported to eduGAIN). | Alex Stuart (UK federation) | Changed to: Identity federation User or Partner has the right to use particular domain names in relation to entityID attributes and <shibmd:Scope> elements; |
| 6 | MRPS | 82 | I understand the general intention of this item, but AMRES verifying endpoint reachability isn't technically equivalent to the reachability for End Users. | Alex Stuart (UK federation) | Changed to: URLs specified in the metadata are valid. |