An open discussion list for topics related to the eduGAIN interfederation service.

[Tomasz Wolniewicz <twoln AT umk.pl>]

Hi Peter, 

   I have said it many times before, but I obviously need to repeat.

1. There is no per-entity filtering except for: eliminating clashes and
a very seldom situation when pyFF caches an error that validator has
missed. To my knowledge this second type of situation may have happened
twice in the history of the current MDS. In general the validator make a
ruling and either accepts or drops the entire feed, and as Maja has
written, a cached older copy of the given Federation feed is then used.

2. No metadata filtering except caused by explicit violation of either
standards or the eduGAIN requirements has ever been applied and I
absolutely agree that any filters not fitting in the rule above should
be used with utmost care. In fact I believe that any such rules must be
clearly documented, i.e. there should be an official document describing
these. To me the eduGAIN metadata profile is exactly such a document and
I actually do not see any sense in having anything else. It there is a
need to add new requirements, the metadata profile should be updated.
From time to time a previously uncaught "harmless" schema violation is
caught. When this happens a new validation rule may be implemented but
before it is applied we talk to all federations that have this problem
with their metadata, ask them to fix it and only add the rule when we
know it will not cause any disruption to the current feeds. A recent
example of this type is mdui:GeolocationHint. There are entities in
eduGAIN which violate "SAML V2.0 Metadata Extensions for Login and
Discovery User Interface Version 1.0". Maja has implemented a filtering
rule but is waiting for the second offending federation to clean things
up before she actually adds the rule to the production.

A softer approach could be applied to the warnings. Here the governing
rule has been that we only list violations of standards or eduGAIN
recommendations. We have made one exception to this - no requested
attributes warning - this has caused an SG discussion which still needs
to be finalised. I have asked several times for a new eduGAIN
recommendations document. I believe we should move all recommendations
from the eduGAIN metadata profile into this one and the SG should be
able to add new recommendations (thus new validator warnings) after a
simple vote.

Yours

Tomasz



W dniu 2016-07-15 o 17:24, Peter Schober pisze:
> I fully agree with Kristof that the OT shouldn't implement any
> filtering the eSG hasn't previously decided upon/approved.
> (Which may be why the filtering discussed in that thread never
> happended? Or maybe was implemented?)

-- 
Tomasz Wolniewicz    
          twoln AT umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576