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: Leif Johansson <leifj AT sunet.se>
  • To: Davide Vaghetti <davide.vaghetti AT garr.it>, edugain-discuss AT lists.geant.org
  • Subject: Re: [eduGAIN-discuss] MDS re-publishes schema-invalid metadata
  • Date: Wed, 25 Sep 2019 13:42:53 +0200

On 2019-09-24 05:16, 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.

I know, its unclear.

This is what I mean: we base eduGAIN on /standards/ that are widely
deployed in production. This means that you have to wait for a new
version of a standard to make it out "into the wild" before you
enforce it.

This is basically a version of the Postel Principle: be careful what
you send and liberal in what you accept.

In this case we are /sending/ data to consumers and we need to be a
bit conservative about what standards we expect those consumers to
support and accept.

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

For me its less obviously the right choice...

Cheers Leif



Archive powered by MHonArc 2.6.19.

Top of Page