[Tf-aai] IdP blacklist proposal

[Martin Matthiesen]

Hello Kai and all,

I can't resist to respond. You are hitting all the points that I went through with Cologne.

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

That was indeed a sticking point with Cologne. But suppose every IdP of the 1800+ Idps checks changes of every SP in required attributes and makes their own decision. That is just not in the greater common interest and it does not scale. I could change the code of my application and make it do something evil, nobody would notice at least not immediately. So basic trust needs to be there and if that is there then why not trust that a new attribute I request I actually need? 

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

And I think we need to get consensus to interpret it to the better. 

>> [...] In both cases you need some level of trust. [...]
> 
> 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.

This was interesting, essentially you re-create the same functionality that is provided by the snippet above. You of course get alerted to changes, but the changes are in any case documented in the metadata themselves and as such quite transparent.

Thanks for the insight, I would still argue that your approach does not add to data security per se compared to the DFN-AAI snippet, but it does help with the data protection people at BBAW who have a documentation page to refer to, and I guess that was your point.
Maybe this discussion could lead to eduGAIN's monitor page to be augmented to transparently show the reuqested attributes. It does a good job in finding non-conformant SPs: http://monitor.edugain.org/coco/?show=list_sps&f_id_status=4

Regards,
Martin