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

[Peter Schober <peter.schober AT univie.ac.at>]

* Tomasz Wolniewicz <twoln AT umk.pl> [2016-07-19 09:31]:
> >> 1. There is no per-entity filtering
> > I know, as I've myself repeatedly spoken out against the currently
> > implemented approach of "dropping the whole federation if a single
> > entity is weird", but that's another discussion.
> Indeed this IS another discussion, and we have already had that. You and
> I seem to be on the opposite ends of understanding what is right here.

I understand and accept the current model. It's main advantage (as far
as I can see) is that by keeping the MDS simpler we can easily build
another MDS (or "eduGAIN") should the need ever came up -- without
having to re-model all the complex things the MDS does/did.
That's just not a likely scenario at this time, I think.
And there are arguments to be made to have more logic in the middle in
order to ease processing on the edges, which may make a better service.
But let's keep this for another time.

> Well, one thing is certain. Maja does know how MDS works, thus it
> clearly follows from logic that my claim is false.

:)

> As you have pointed out this particular rule has been extensively
> discussed by the SG with no definite conclusion, however the the
> flow of this discussion was interpreted by us as an agreement to
> implement a form of sane filtering, which has been done as Maja has
> described. The initial proposed rule was more strict requiring
> urn:mace but has been reduced to urn: as the result of the SG
> discussion. As a result of that discussion the French federation
> cleaned up their "offending" entities, and it looked like everyone
> was happy.

I can agree with all of that, but that's not the transparency I'd
expect from this shared infrastructure. None of these consequences
from and after the discussion where discussed or even announced,
AFAICT.

> The fact that we have done this does not change the fact that I
> still believe that no rules should be implemented without SG
> authorization. The entityId should be re-examined and either
> officially accepted or withdrawn (I would vote for the first). We
> need a proper specification of how such rules should be introduced
> and documented.

We all agree on that, I think.

> Having said that, I must point out that not everything seems to be a
> binary decision. One example may be empty elements like GivenName inside
> of ContactPerson. Following the UK rules, we have decided to throw
> errors in such cases. Our interpretation is that the only reason for
> such elements to be present is to pass information, therefore no
> contents results in an error. There are a number of similar cases, I
> gave just one example but we may provide a full list.  I hope people
> will not find this interpretation invalid?

I called dropping an entire federation from eduGAIN (yeah, I know,
keeping a cached copy until it expires, only then all their entities
vanish from the MDS) because of such issues "draconian" in the past.
  But I also understand this gives the OT much better leverage in
getting participant federations to comply ("or else") and so
ultimately leads to improved metadata quality and reduced chances for
errors in all other federations and for all entities parcitipating in
eduGAIN.

> Finally, it should be explained that the validator also depends on
> how software like Sibboleth MDS and pyFF implement standards
> validation.  These two are a part of the entire flow, thus if they
> choke on something so does the whole validator. Here we just trust
> that they do the right thing.

Sure. Preventing errors in end-entity deployments should be/remain a
very high priority. FWIW, I also make use of the Shib SP's "brute
force validation" feature as one part of my validating chain, so if
that throws up on provided metadata my commit will fail.

-peter