Shibboleth Developers

[Kristof BAJNOK <>]

On Friday 19 March 2010 15.07.52 Scott Cantor wrote:
> I'd think the best option is to ensure there are some hooks in the
>  consent layer or some kind of documented mechanism involving the
>  database or whatever, and then just let people build in rules that
>  create filter policies based on whatever information they want.

Yep, but it's not how uApprove works (AFAIK). It lets the IdP pull in and 
filter the attributes and then determines if this set can be released or the 
user needs to be asked. The IdP can not step in later. 

> But my impression is that people won't rely on back channel approaches
>  that can't guarantee (at least approximately) that the data can be
>  gotten, or that consent can be asked in real-time. If it's 50/50 based
>  on whether consent was given at some other time, I think it's not going
>  to fly.

As Peter has already pointed out, there are SPs that can receive/fetch the 
attributes even without the users' approval. You as an IdP administrator can 
only guarantee back-channel attribute availability to such SPs, other SPs 
should be aware that it depends on the user, therefore it's unreliable. 

If people start to use persistent nameids while paying attention to various 
privacy amusement (such as 95/46/EC), they will find that they need to 
disable the attribute query ProfileHandler to be on the right side. I'm 
positive that this should be handled by a consent layer instead.

Kristof