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

[Janos Mohacsi <mohacsi.janos AT kifu.gov.hu>]

Dear All,


I my opinion we should implement the Robustness Principle ( 
https://en.wikipedia.org/wiki/Robustness_principle ), however it is tend 
to be criticized.

We should be be very strict what is going into eduGAIN metadata, since we 
don't know which implementation will consume them. On the SP side we 
should advocate to be as permissive as possible.

Therefore we should define what  and how can be  published to eduGAIN SAML 
Profile.

Best Regards,



Janos Mohacsi
Chief Development Officer, Network Engineer
KIFU NIIF Program, HUNGARY
Co-chair of Hungarian IPv6 Forum
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Tue, 24 Sep 2019, Davide Vaghetti wrote:

> On 24/09/19 00:35, Leif Johansson wrote:
> > On 2019-09-24 00:32, Peter Schober wrote:
> > > * Tomasz Wolniewicz <twoln AT umk.pl> [2019-09-23 22:12]:
> > > > eduGAIN validator was using a newer xml.xsd and the validation passed.
> > > >
> > > > So what is the correct approach here?
> > >
> > > As I said, the current Shibboleth SP release fails to load such
> > > metadata. Sure, we can try to get that changed upstream and then wait
> > > a few years until it's deployed everwhere where a Shib SP is running
> > > today, hoping such XML will never occur in the meantime. And even when
> > > it does and things break (SPs failing to update, leading to expired
> > > metadata days or weeks later) we can still tell the SP owners that
> > > we've let this error (or "former error") through on purpose because we
> > > don't consider it an error any more and they should get their software
> > > fixed. Let's see how that goes.
> > >
> > > Or... we could be as conservative as possible in what we publish to
> > > avoid any such breakage (to me that means not being liberal in what I
> > > accept, too), esp. in cases that make no sense at all (such as empty
> > > xml:lang="" XML attributes or other effects of improper tooling or
> > > human errors, not concious decisions that the XML should in fact look
> > > exactly like that).
> > >
> > > But I've already made those choices for my (or our federation), it's
> > > up to us all to decide how the MDS should behave being the man in the
> > > middle. If the MDS allows it that doesn't mean we can't filter it out
> > > in our local feeds, that merely raises the bar a bit further what it
> > > means to particiate in eduGAIN for member federations.
> > >
> > > Cheers,
> > > -peter [ offline for the next days ]
> >
> >
> > I have to agree with Peter here. The issue isn't whats right but
> > what works.
>
> Sounds good, but I'm a bit concerned about the definition of "what
> works", for who? with what software and configuration? We have agreed
> standards and BCPs exactly to better interoperate, which by the way is
> what eduGAIN is all about.
>
> If we need to add additional rules deviating from the current standards
> form XML validation, I'd say we should codify them in the current
> eduGAIN SAML profile, which is the source of authority for the checks of
> the current eduGAIN metadata validator v2.
>
> BTW, let me also praise the eduGAIN OT for using an updated xml.xsd from
> W3C instead of relying on an expired version.
>
> Cheers,
> Davide
>
> >         Cheers Leif
>
> --
> Davide Vaghetti
> Consortium GARR
> Tel: +390502213158
> Mobile: +393357779542
> Skype: daserzw