[Tf-aai] IdP blacklist proposal

[Kai Zimmer]

Dear Martin,
>> 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

You're absolutely right. But still the SP could change its demands and 
you wouldn't notice it.

>> 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.

Well done. But GDPR still leaves some room for interpretation - for 
better for worse.

>> 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.

You're right - it's about trust. In case of the BBAW there's not only 
the data security officer involved when 'introducing new working 
methods' (like IdP), but also the staff council, administration and 
more. I was very happy when they agreed to find the IdP useful, but they 
insisted to have me document which attributes are released for each SP 
on an internal website. Dieter kindly pointed me to this list

 >https://infra.clarin.eu/aai/prod_md_about_spf_sps.xml

So that's where i'm generating my AttributeFilterPolicy-Snippets from. 
And also my documentation. It's not a big deal, but that's why i wrote 
that the DFN-Snippet you mentioned doesn't help me there.

Best regards,

Kai