[Tf-aai] IdP blacklist proposal

[Martin Matthiesen]

Dear Kai,


>> https://doku.tid.dfn.de/de:shibidp3attrfilter#freigabe_der_wichtigsten_attribute_fuer_clarin-sps
> 
> In my opinion (as an IdP administrator) this document is not helpful at
> all.

Thanks for the input from an IdP admin point of view. I got the link to this document actually from the IdP admin in Potsdam when we tried to figure out why they did not release attributes. They assured me that they implemented the rules mentioned and we then figured out that the problem was on my side.

> It suggests to release ten attributes although many of them are not
> necessary or requested by the SPs.

Attributes are only released if requested by the SP.

<!--onlyIfRequired="true" kann hier weggelassen werden, da ab IdPv3.2 Default-->
https://wiki.shibboleth.net/confluence/display/IDP30/AttributeInMetadataConfiguration

> Even though the SPs have signed CoCo,
> many german data security officers will struggle with this 'rule of a
> thumb'.

Even if only requested attributes are released? GDPR explicitly allows processing of personal data if there is a good reason. And a user wanting to release their own personal data to productively use a service promising to handle the data properly seems like a good enough reason to me. I do have first hand experience with the struggles of the Data Protection Officer in Cologne who was sympathetic to my CoCo request but showed me the exact legal reasons why he had to insist on a form with a stamp. He had convinced me and I send the forms (with 2 management signatures and the stamp) in March 2017 and got connected like that. In April 2018 they informed me that they can support the CoCo. I did not ask too much why and what changed, but if they could do it right before the GDPR came into effect, I think a lot of Data Protection Officers can do the same.

> I think it would be better to keep a list of individual
> AttributeFilterPolicy-Snippets for each SP according to the demand for
> data thrift in the GDPR/DSGVO.

I think this is impractical for interoperability. An SP promises via CoCo that it needs the requested attributes and handles them properly. The configuration above ensures that the IdP only releases those attributes. I don't see how a manual process improves anything, since the IdP will not be able to perform large audits on the SP application layer anyway. I still cannot see how a promise on a piece of paper approved once is worth more than the same promise delivered in an automated fashion. In both cases you need some level of trust. In the later case a broken privacy policy stops attribute release (at least in DFN-AAI) in the former, not.

Regards,
Martin