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

[Peter Schober <peter.schober AT univie.ac.at>]

* Порхачев Василий <porhachev AT runnet.ru> [2018-03-15 12:57]:
> We see that it is a rather complicated task to get all the issues
> inline both with eduGAIN traditions and local laws.

I don't think anything I said has anything to do with local laws or
eduGAIN specifically. E.g. demanding that IDPs reject unsigned SAML
authentication requests (which is included in what you're mandating)
does not solve an existing problem, but will prevent you from using
probably 90% or more of existing SAML SPs in the world (whether they
join your federation locally or via interfederation is irrelevant).
You're requirement goes too far (and I'd claim for no good reason).

I also doubt local laws will prevent people from using supported
software versions from GNU/Linux distributions. As none of these will
be the "latest stable version" available for each software product
(distributions often "freeze" a certain version and only back-port
security fixes) you're basically forcing everyone to compile all
software from scratch, every time a new stable release for anything
comes out. I don't think there exists any proof that this make
anything more secure, and the operational effects for your members
will be massive. (Or this rule will be ignored from day one, in which
case it's pointless to put it into the rules in the first place.)

Everything else is mostly either bad wording (which can happen only
too easily, esp if one's writing policies in something other than the
native language) or bad ideas (the choice of attributes for the
forced-to-release set) or bad habits (making up attributes in other
people's namespaces).
These will only make interop and cooperation harder (needlessly) but
will not cause issues in the order of your "protocol messages must be
signed or rejected" rule.

Best regards,
-peter