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

[Tomasz Wolniewicz <twoln AT umk.pl>]

Hi Peter,


W dniu 2016-07-18 o 13:58, Peter Schober pisze:
> 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.
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 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:
> [...]
[ . . . ]
>
> 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.
Well, one thing is certain. Maja does know how MDS works, thus it
clearly follows from logic that my claim is false. This entityId filter
is the one "offending" case.

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.
The fact that we have done this does not change the fact that I still
believe that no rules should be implemented without SGauthorization. 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.

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?

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.

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

-- 
Tomasz Wolniewicz    
          twoln AT umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576