[Tf-aai] IdP blacklist proposal

Martin Matthiesen martin.matthiesen at csc.fi
Fri Sep 6 11:04:31 CEST 2019


Hi,

I support this proposal, having played that game with University of Cologne. I think it was necessary at the time to break the ice, Cologne is now supporting the Data Protection Code of Conduct. So is University of Potsdam. Tübingen has also been releasing attributes for years based on the assumption that attribute release to German Universities is legal and EU Universities and Public institutions should be treated equally.
So yes, hiding behind complicated forms should not be accepted.

In our last Centre Meeting (5.9.) we discusssed the process in a bit more detail, I hope I interpreted the gist of the discussion correctly, I added some pointers:

The blacklisted IdP should be properly informed beforehand and given a chance to respond. German IdPs (so far 100% of the cases) can be presented with this document:
https://doku.tid.dfn.de/de:shibidp3attrfilter#freigabe_der_wichtigsten_attribute_fuer_clarin-sps

Still unwilling IdPs will be taken out of the Discovery Service and an FAQ will be placed promintenly on the DS (e.g. as part of "Please help, I cannot find my provider")
Users will be informed that their IdP does not make attributes available with reasonable effort even though CLARIN supports the CoCo, R&S and the service is question is a member of the SPF.
Users will be informed that they can apply for a CLARIN account and at the same time will be encouraged to contact their IdPs and request a change to their access policies.
The CLARIN IdP will be regulariliy monitored for accounts from users coming from blacklisted IdPs. User stats will be added to the IdP specific information.

Some comments:

In my view high and low user numbers are both an argument to automate the process: In case of low numbers the red tape burden is too high per user and in case of high numbers the IdP should be happy to support CLARIN directly instead of forcing its users to apply for CLARIN accounts while applications on paper are processed.
In the Centre Meeting the focus was a lot on helping the user to get access. The user should not be primarily bothered with the attribute release discussions we had with his home organisation. I think the black list documentation should reflect that and is more effective that way. I am sure some IdPs do not always agree with their data protection departments either.

IdPs (and data protection officials) also need to understand that the automatic CoCo checking is actually safer for users compared to a one-time form approval. DFN checks the Privacay Policy link and in there the CoCo link regularily and if it cannot find it, it unsets the Entity Category, effectively blocking access. This happened to me for pure technical reasons (The DFN test script could not handle JavaScript), but is generally a good idea.
Some IdPs might argue that filling out a form is not that bad, but we should argue that it simply does not scale (whihch it doesm't: Cologne wanted to have a stamp from CSC at the time which caused a fair bit of confusion, we just and just managed to find one...).

I think it is a good sign that we are in the position that we have a lot of IdPs who play nice and we can afford to refuse to jump through every hoop that is placed in front of us.

Cheers,
Martin

-- 
Martin Matthiesen
CSC - Tieteen tietotekniikan keskus
CSC - IT Center for Science
PL 405, 02101 Espoo, Finland
+358 9 457 2376, martin.matthiesen at csc.fi
Public key : https://pgp.mit.edu/pks/lookup?op=get&search=0x74B12876FD890704
Fingerprint: AA25 6F56 5C9A 8B42 009F  BA70 74B1 2876 FD89 0704

----- Original Message -----
> From: "Dieter Van Uytvanck" <dieter at clarin.eu>
> To: "tf-aai" <tf-aai at lists.clarin.eu>
> Sent: Thursday, 5 September, 2019 12:11:32
> Subject: [Tf-aai] IdP blacklist proposal

> Dear all,
> 
> As discussed earlier on slack
> (https://clarineric.slack.com/archives/C163MM2HL/p1563797213002700) and
> today in the centre committee, we would like to propose the following
> blacklisting approach for IdPs that consciously not releasing necessary
> attributes:
> 
> https://office.clarin.eu/v/CE-2019-1487-identity_provider_blacklist.docx
> 
> So far there seems broad support for this. Unless you think this is a
> bad idea I would like to put it forwards for approval during the centre
> committee meeting in Leipzig.
> 
> best regards,
> --
> Dieter Van Uytvanck
> Technical Director CLARIN ERIC
> www.clarin.eu | tel. +31-(0)850091363 | skype: dietervu.mpi
> _______________________________________________
> Tf-aai mailing list
> Tf-aai at lists.clarin.eu
> https://lists.clarin.eu/cgi-bin/mailman/listinfo/tf-aai



More information about the Tf-aai mailing list