Skip to Content.

edugain-discuss - Re: [eduGAIN-discuss] MDS re-publishes schema-invalid metadata

edugain-discuss AT lists.geant.org

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

List archive


Re: [eduGAIN-discuss] MDS re-publishes schema-invalid metadata


Chronological Thread 
  • From: Maja Wolniewicz <mgw AT umk.pl>
  • To: edugain-discuss AT lists.geant.org
  • Subject: Re: [eduGAIN-discuss] MDS re-publishes schema-invalid metadata
  • Date: Tue, 24 Sep 2019 08:29:22 +0200


Wiadomość napisana przez Davide Vaghetti <davide.vaghetti AT garr.it> w dniu 24.09.2019, o godz. 05:16:



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.

As a matter of fact pyff used on eduGAIN aggregation stage has its own schema directory with newest xml.xsl 
http://www.w3.org/2009/01/xml.xsd
That's why it doesn't choke on empty xml:lang.
I've replaced the pyff's xml.xsd with the UKf's version and then pyff failed.
 
BTW pyff's schema directory used with xmlsectool.sh --schemaDirectory ...
causes the error 
ERROR XMLSecTool - Invalid XML schema files, unable to validate XML

Maja
Cheers,
Davide


Cheers Leif


--
Davide Vaghetti
Consortium GARR
Tel: +390502213158
Mobile: +393357779542
Skype: daserzw


--
Maja Górecka-Wolniewicz
Uczelniane Centrum Informatyczne
Uniwersytet Mikołaja Kopernika w Toruniu
Coll. Maximum, pl. Rapackiego 1
87-100 Torun, Poland
tel.: +48 56-611-2740
fax: +48 56-611-2725 
tel. kom.: +48-693032574






Archive powered by MHonArc 2.6.19.

Top of Page