Page History

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???

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? 

90

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

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?

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.

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. 

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?

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? 

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.