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

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

Hi,

>> One could even think the the correct approach is to have people
>> update their fairly ancient schemas rather disallowing something
>> that has been in the standard for 15 years.

That's my thinking as well.

> This stuff breaks deployments in the wild and the Shibboleth SP
> (should it be the only one) is probably the most often used SAML
> implementation on the globe. So -- contrary to what Davide said -- I'm
> very happy old schemata were used in the software I had at hand
> otherwise we would only have found out about that in a few days (or
> weeks) once Shib SP admins all over the world started asking their
> local federation operator why their SP doesn't know any IDPs anymore.

From what I understand, the empty lang's are in the standard since 2001.

If there were deployments out there which date back to <2001 then they
would unexpectedly get problems with our "new" feeds. They have my
sympathy for that. They also have my un-sympathy for running software
that is 1.5 decades old as well though. (Yes, I realise that it's
actually impossible to have a SAML2 entity running since before 2001)

For any deployment that is younger than 2001 they are simply bit by a
bug in the software; the software vendor failed to keep up to date with
the evolving specification. Had they included the then-current schema
definitions in their product, then there would have been no issue.

So in essence, we are talking about buggy software. Are we going to
change eduGAIN wide rules because there is one buggy implementation?

This feels wrong, for several reasons.

For one, we are basically pinning all of eduGAIN to a XML definition of
2001: if anyone wishes to use a not backwards compatible feature of
later editions of XML (whatever and whenever those may be) any such
desire would meet the same argument "but there are Shibboleth
deployments still at 2001".

Also, I recall a precedent where eduGAIN chose to go the opposite route
- when SAML2int was chosen as a required interop baseline. One
implementation, simpleSAMLphp, used a NameID format that didn't match
SAML2int requirements. Rather than deviating from SAML2int to allow
simpleSAMLphp to stay in its previous state, the implementation had to
change. Yes, that meant many installations had to upgrade, and it was a
significant operational issue. Yet, it was done.

At that particular incident, it seems like everyone was happy to blame
the implementation and insist on specification-correctness, even if that
led to significant operational complexity.

(my apologies if my recollection of events is inaccurate)

What is different now compared to that other issue?

> "People should just update their software so that we can support
> corner cases noone ever asked for" is a possible approach to such
> scenarios. It's certainly not my preferred one, though.

Just as one data point, we also encountered an issue with language tags
that are unspecified in a product we develop for eduroam, eduroam CAT.
It's actually quite a popular option for admins out there to select
"language = default/other". I find it dangerous to do away with advice
given by an IETF BCP so quickly.

I'm entirely with Davide here: if we do want to enforce this
restriction, let's make it an explicit part of the rules.

Greetings,

Stefan Winter

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