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

[Stefan Winter <stefan.winter AT restena.lu>]

Hi,

> SAML metadata is the protocol I’m talking about here, not XML. Metadata 
> should be conservative in what it "sends", if there is a breaking 
> difference between an old and new version, what is "sent" should be in the 
> intersection of compatibility. Metadata clients that break in the case 
> where something in metadata is outside the intersection should be fixed so 
> that they don’t break in that case.

In the general case, that's not good advice as breaking differences
often lead to a case where the intersection is empty.

Even if there is an intersection, it typically means that the new
(incompatible) features of later versions of the protocol in question
can never be used, effectively freezing deployment to the old state
perpetually.

As a not-so-funny analogon: everyone has IPv4, not everyone has IPv6.
And they are incompatible. So you should always use IPv4? (I know, in
this particular protocol workarounds for an upgrade have been created to
overcome the hard incompatibility; we're not in that position with XML
though)

Personally, I'm more on the side of "move on or at some point you will
be left behind". A two-digit number of years to move on is typically
sufficient to get virtually everyone on board.

In this particular case here, refraining from using empty lang is indeed
compatible with all editions of XML. If this freeze-in-time (and thus
not being able to use empty lang at all - which we just heard might
actually make sense in the case of "Logo") is what we want, then that's
fine. Like I wrote earlier, we then either

a) need to collectively agree to base our thinking at the *latest*
edition of XML, and then codify that fact and that lang=empty is
additionally forbidden in our rules (eduGAIN SAML2 profile, or better
SAML2int) rather than let the fact linger implicitly in the brains of
people who read this thread or
b) make explicit that we continue to enforce XML Second Edition as
written in the SAML2 spec

We then have to hope that nothing else that was changed in Edition 3+
will come back to bite us. I'm not enough into XML to know by heart.
What I did see was that external entity definitions are now more relaxed
than 2004 (special characters being allowed where they weren't before)
but I would hope that we are not using those. Of course if eduGAIN OT
wanted to be mean they could define an external entity &edugain; and put
it on a URL with special characters. :-)

Greetings,

Stefan Winter

> 
> Nick
> 
>>
>> Even in the IETF, where Jon's principle emerged, a clear violation of a
>> spec is generally a totally fine justification to discard a packet.
>>
>> That's why protocols are often designed with a viable upgrade path so
>> that new versions don't wreak havoc on a deployed base.
>>
>> Sometimes that's not possible, and yes, then people have to upgrade to
>> remain in the game. To give an example, what used to be the simple RFCs
>> 821/822 on email syntax and transport has changed very significantly
>> over time, and an implementation only adhering to those ancient original
>> specs will not have a good time today; chances are that email from such
>> systems gets classified as spam for not adhering to up-to-date
>> refinements of the specs (so much for being liberal on reception in that
>> particular domain).
>>
>> Now I absolutely don't want to judge whether the jump from forbidden to
>> allowed, without backward compatibility guidance, was unavoidable in the
>> XML spec creation process (TBH, a version identifier "1.1" to handle
>> this as an easy test by recipients comes to mind). What I do see is that
>> this was a backward incompatible change and we have to live with that.
>>
>> Looking at the timing of the specs, I have trouble having sympathy with
>> Shibboleth here. XML 1.0 allowed empty lang tags from 2004 onwards.
>> SAML2 was finalised in 2005. When writing an implementation of SAML2,
>> there was never any time window where using an earlier XML spec was
>> justified. I.e. a day one bug, which (unluckily) wasn't noticed early
>> when the deployed base was small to non-existent.
>>
>> I certainly see that it is hard to update a large deployed base. Ask
>> every email admin out there how often they have to cope with new strides
>> to keep their email servers whitelisted, DNS entries up-to-date etc.
>>
>> Can we maybe get a statement from the Shibboleth consortium that they
>> will update their XML spec ASAP? Did someone open a bug report yet,
>> maybe with a reply?
>>
>> My suggestion would be that we see how long it will take to "wither out"
>> the problem. Once the oldest version with a 2001 variant of XML goes out
>> of official support by the consortium, that would be a day where we can
>> clear the use of empty lang tags, if we want that at all. Until then,
>> the corresponding metadata should ideally be marked as "having a
>> sigificant interop risk" or similar during import.
>>
>> If we do not have any intention to support empty lang tags (there are
>> reasons to allow them, IMHO, but that would be a different thread) then
>> we can put that in paper and subsequently reject incoming metadata with
>> that inside. Doing away with empty lang tags as "something that makes no
>> sense at all" is IMHO a non-argument. BCP47 does not read as nonsensical
>> to me; it is a document that got a real lot of scrutiny by many clever
>> protocol people.
>>
>> Greetings,
>>
>> Stefan Winter
>>
>>>
>>> Nick
>>>
>>> On 23 Sep 2019, at 16: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 ]
>>
>>
>> -- 
>> Stefan WINTER
>> Ingenieur de Recherche
>> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
>> de la Recherche
>> 2, avenue de l'Université
>> L-4365 Esch-sur-Alzette
>>
>> Tel: +352 424409 1
>> Fax: +352 422473
>>
>> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
>> recipient's key is known to me
>>
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature