|comment #||Line/Reference #||Proposed Change or Query||Proposer / Affiliation||Action / Decision (please leave blank)|
|1||NA||Include names and organizations of contributing authors and editor(s)||Nicole Roy||accepted - will add.|
|2||144||Does 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 Pempe||no this wasn't intended, this was about clarity for people consuming metadata. Will update and add proposed wording changes to make this clearer.|
|3||144||I 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 Pempe||clarify that this is not about stopping federations filtering as they need to.|
|4||131 (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.
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???
|5||141 (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?||SURFconext||no - 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.|
|6||143 (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.||SURFconext||no action needed here|
|7||153 (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.||SURFconext||no action needed here|
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 Barton||add this as an explicit recommendation in the section recommending strategy development.|
After “eduGAIN strategy” add “(cf. Recommendation 2.3)”, if that is indeed what the working group means.
|Tom Barton||see above|
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 Barton||yes - clarify in text|
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 Barton||yes - this would be part of the SAML profile|
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 Barton||change to REFEDS Assurance Framework|
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 Barton||2.5 is intended more as a technology watch / R&D and not part of the current eduGAIN wokplan.|
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 Barton||add more detail to the evidence for why we want to change the governance structure - it's a lot more than just low participation.|
|15||144 (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 Stuart||Please see response to point 4 - yes, consistency is not at all clear at the moment and this needs a significant conversation.|
|16||131 (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 federation||remove "as appropriate" and add clarity as per the discussions in 4 and 15.|