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

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

Hi,

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

It looks like I have to correct myself and this reveals a third option
(which is a bit dull and I hope it will not actually be considered, but
I do want to mention it).

Looking at the OASIS SAML 2.0 Core Specification, I read in the
introduction:

"SAML assertions and protocol messages are encoded in XML [XML] ..."

And the normative references section states:

"[XML] T. Bray, et al. Extensible Markup Language (XML) 1.0 (Second
Edition). World Wide Web Consortium, October 2000. See
http://www.w3.org/TR/REC-xml";

So SAML 2.0 pinpointed the Second Edition, which is from 2000 (despite a
2004 one being available).

The third option is thus to consider Shibboleth as being the only
correct implementation, and demanding that all other implementations of
SAML which use a later edition of the XML Spec are all buggy and have to
revert to the Second Edition.

From which it would naturally follow that using an empty lang tag is not
allowed; it is and has always been codified like that in the SAML2 spec
by way of its hard reference to a specific edition of XML.

Greetings,

Stefan Winter

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

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

Attachment: signature.asc
Description: OpenPGP digital signature