Shibboleth Developers

[Christopher Bongaarts <>]

Scott Cantor wrote:
> > Also, it would be possible to bring up the consent page even if the IdP
> > wasn't pushing attributes.  So you could ask the user's consent for the
> > attributes that would be pulled by the SP.  Not sure if this is
> > desirable.  It is still obviously mutually exclusive with the "always
> > ask" option and in theory IdP deployers can create filter policies that
> > would return different results for push vs pull, but I doubt anyone has
> > ever done that.
>
> The back channel thing also answers my question about use of cookies to
> track consent (as in, probably not a good idea).

By itself, no, but if you use a cookie just to track the long-term 
consent state, that would enable use of a different mechanism to signal 
to the AA that is it OK to release for *this session*.  This has the 
advantage of relieving the short-term state mechanism from a persistence 
requirement - you don't need to store the consent state of all your 
users times all your SPs, you just need to store the currently logged in 
 users and the SPs they're actually using.  On the downside, the 
long-term consent tracking becomes per-browser instead of per-user, 
which doesn't seem ideal for most uses.

I would not use the system above--just noting that it has a different 
set of tradeoffs for complexity/storage/load that some deployers might 
prefer.

--
%%  Christopher A. Bongaarts   %%  

       %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%