The final version of the White Paper taking into account the comments from the consultation can be found here.

This consultation is now CLOSED

Background

The eduGAIN Futures Group was established with the following goals:

  1. To review the REFEDS Baseline Expectations document and make proposals for changes to eduGAIN to support the baseline.  
  2. To identify key issues with current eduGAIN service provision and make recommendations for improvements (e.g. support mechanisms for CoCo and R&S, lack of service offer to Service Providers, technology support for OIDC etc). 
  3. To review the governance model for eduGAIN and make recommendations for improvements.
  4. To cross-reference proposals with other working groups and the eduGAIN service teams.  

Out of scope:

  • Direct policy revision - this work will be carried out based on the recommendations of this group.

Full information about the group can be found at: eduGAIN Futures Working Group Charter

Overview

The eduGAIN Futures Working Group met on a two-weekly cycle since its inception to produce a set of recommendations for the eduGAIN Steering Group and the eduGAIN Service Team.  A draft white paper has been produced and is now shared with the wider FIM community for consultation and comment.


The document for the consultation is available as a pdf attachment.  All comments should be added to the changelog below or sent directly to: edugain-discuss@lists.geant.org.  Comments posted to other lists will not be included in the consultation review.

Change Log


comment #Line/Reference #Proposed Change or QueryProposer / AffiliationAction / Decision (please leave blank)Status
1NAInclude names and organizations of contributing authors and editor(s)Nicole Royaccepted  - will add.DONE
2144Does this mean that all participatings federations would have to switch to an opt-out policy? Our (DFN-AAI) constituency wouldn't accept that, I'm afraid... (currently, 314 out of 374 IdPs are exposed to eduGAIN - after all).Wolfgang Pempeno this wasn't intended, this was about clarity for people consuming metadata.  Will update and add proposed wording changes to make this clearer.DONE
3144I see here a possible conflict with Baseline Expectations FO1 and FO3, especially in terms of filtering out untrustworthy entities from the eduGAIN downstream metadata. Currently, this only applies to SAML1-only-entities, but the next step will be to remove SPs without a Privacy Statement URL. If the Steering Group were to ban such a thing, we'd have a problem...Wolfgang Pempeclarify that this is not about stopping federations filtering as they need to.DONE
4131 (rec 1.2)

We support adding ther ability to filter individual entities. We believe eduGAIN should implement more basic checks at this level, because now entities are dropped downstream (e.g. the UKAF filtering), while the checks are reasonable, doing it decentrally makes the system unpredictable (works in some federations, dropped from others). We should take this kind of actions at the source. Even mandate that downstream federations stop this kind of filtering altogether - either do it centrally or not at all.

SURFconext

the issue here is that entities are not aware that they are being filtered out - is there a way to better manage this centrally in terms of communication so that there is awareness where there is a problem.  we don't want to say that filtering cannot happen but can we develop a better practice for this (dashboard for filtering processes??). 

Strong support for more clarity and better communication around the filtering process - this would suggest a strong work item for eduGAIN in 2023. 

With the current set up no filtering is possible. This needs to change.

Possible solution - central model offered by eduGAIN but managed by federations???

DONE
5141 (rec 2.1)What is required here of IdPs exactly? Supporting 'personalized' as an IdP means that you must release that bundle to all SP's that request it. Does this mandate that all IdPs will be doing that? And what happens if they don't?SURFconextno - there would be no requirement to support personalised but there would be a minimum requirement to support anon.   Add more clarification to this section  - making sure it is clear that it is for the available Service Providers for the IdP. DONE
6143 (rec 2.3)A clear mission and strategy for eduGAIN are in our opinion required to know what actions you need to take to get there. Some of the proposed recommendations depend on what the mission/vision of eduGAIN actually is. However, we accept that this does not exist yet and we believe that e.g. establishing a better governance model will help if this new governance will prioritze defining a mission and vision for eduGAIN.SURFconextno action needed hereDONE
7153 (rec 3.1)We wholeheartedly support a balanced steering group with a real mandate to decide the direction and operation of eduGAIN and think it's instrumental in bringing about the other changes proposed in the document within a reasonable timeframe or at all.SURFconextno action needed hereDONE
8

89-99

This is a clearly stated and important recommendation, but it is not among those listed in the Recommendations section and so may be overlooked. Should it be added to the Recommendations section? 

Tom Bartonadd this as an explicit recommendation in the section recommending strategy development.DONE
9

90

After “eduGAIN strategy” add “(cf. Recommendation 2.3)”, if that is indeed what the working group means.

Tom Bartonsee aboveDONE
10

135-136

Recommendation 1.4 would create clear guidance as to a required standard. Is the intention to make this a formal eduGAIN policy requirement, as in Recommendation 1.5?

Tom Bartonyes - clarify in textDONE
11

137-138

Does being a “formal eduGAIN policy requirement” mean that it is required for continued membership in eduGAIN (modulo staging and applicability caveats)? If so, it might improve clarity if this is stated somewhere in the report. Perhaps in the Introduction, where some existing examples of such formal policy requirements could be noted.

Tom Bartonyes - this would be part of the SAML profileDONE
12

137-138

Recommendation 1.5 uses the term Assurance, which is often used to refer to various different things. Should the recommendation specify which? For example, it might refer to the REFEDS Assurance Framework, or explicitly refer to one or more of identity, authentication, and attribute assurance. 

Tom Bartonchange to REFEDS Assurance FrameworkDONE
13

150-151

Recommendation 2.5 asks for emerging technologies to be monitored so that corresponding implementation roadmaps can be created. Recommendation 1.5 also creates a roadmap, but makes (staged and applicable) implementation a formal eduGAIN policy requirement. Should Recommendation 2.5 do likewise?

Tom Barton2.5 is intended more as a technology watch / R&D and not part of the current eduGAIN wokplan.DONE
14

153-154

Recommendation 3.1 would change eduGAIN governance, apparently to address low participation in its current form. Should any additional, more future-oriented, objectives be identified to be addressed with a new governance structure? For example, other recommendations envision that in future there should be implementation roadmaps whose suitable implementation is a formal eduGAIN policy requirement. Do current governance processes support this ability well enough? 

Tom Bartonadd more detail to the evidence for why we want to change the governance structure - it's a lot more than just low participation. DONE
15144 (Rec 2.2)

It is unclear what consistency means in this recommendation. The UK federation believes federations must be able to determine their own policy for disallowing import from eduGAIN, whether this is due to an entity's failure to meet a technical profile or because of behavioural policy, so we would not support defining a consistent policy on entity import/export.

If consistency were solely about harmonizing architecture, metadata feeds and metadata refresh, it would be a major piece of work to define what a consistent position would be (with no guarantee of resolution) and then migration to it.

A great deal of value could be achieved by requiring that eduGAIN member federations publish their policies and provide eduGAIN operations with the locations of those policies. This will serve as validation (or otherwise) to Service Providers' assumptions about federations' policies.

Alex StuartPlease see response to point 4 - yes, consistency is not at all clear at the moment and this needs a significant conversation.DONE
16131 (rec 1.2)"as appropriate" is doing a lot of work in this recommendation. The UK federation supports the technical work to develop the eduGAIN infrastructure. However the policy for filtering must be based on technical or security reasons and not on the purpose of the entity (for example whether it's a test entity or the entity's business model) UK federationremove "as appropriate" and add clarity as per the discussions in 4 and 15. DONE
  • No labels