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

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

Tomasz,

Since you explicitly address me, about claims I never made:

* Tomasz Wolniewicz <twoln AT umk.pl> [2016-07-18 08:33]:
> Hi Peter,
> 
>    I have said it many times before, but I obviously need to repeat.
> 
> 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.

I have not claimed the MDS performed per-entity filtering, neither
filtering of individual entities (as in the case of the invalid URN
urn:federation:MicrosoftOnline, or the current case of domains in the
RFC6762 TLD), nor filtering of the content of individual
EntityDescriptors (which some asked for in the past, cf. the MS-ADFS
RoleDescriptor fail).

> 2. No metadata filtering except caused by explicit violation of
> either standards or the eduGAIN requirements has ever been applied

Maja claimed something else only yesterday:

* Maja Wolniewicz <mgw AT umk.pl> [2016-07-17 15:33]:
> The eduGAIN validator raises error for entities which name do not
> start with one of:
> http://
> https://
> urn:
[...]
> The metadata validation is based on the eduGAIN validator, so a
> federation with an entity not following required schema is rejected
> (and the last successfully validated feed is used until the
> validUntil is correct)

Looking at your claim a bit closer:

> I absolutely agree that any filters not fitting in the rule
> above should be used with utmost care. In fact I believe that any
> such rules must be clearly documented, i.e. there should be an
> official document describing these.
> To me the eduGAIN metadata profile is exactly such a document and I
> actually do not see any sense in having anything else.

The (optional) eduGAIN Metadata Profile does not ever mention the term
entityID (or URI), let alone provide text to limit its values
according to the filtering described by Maja.
Neither does the referenced MetaIOP, nor (not referenced) saml2int.
Neither does SAML Core (cf. 1.3.2, URI Values) nor SAML Metadata
(cf. 2.2.1). I'm running out of standards to check.

I don't know where else I should be looking for "standards or the
eduGAIN requirements" that would support your claim that /this/
limiting is based on published standards of any kind -- but I may be
overlooking something, of course.

So either Maja doesn't know how the MDS works or your claim that the
MDS only implements filtering based on "standards or the eduGAIN
requirements" is false.


On another note, the (new) filtering based on the above URI schemes
also is not sufficient to deal with the two recent (known to me, i.e.,
discussed on the eduGAIN eSG or discuss lists) cases, which were:

1. Syntactically valid anyURI values using URN namespaces that are not
registered with IANA (cf. the thread "New rule in the validator").
None of the cases presented are caught by the above rule.

2. DNS domains in the .local TLD

Cheers,
-peter