Shibboleth Developers

["Scott Cantor" <>]

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

Per our chat discussion, I do favor the idea of allowing a non-database
storage option based on the clustering/replication code and supporting some
degree of persistence there.

My justification for that is to encourage deployment of consent, which I
think is required to make federation scale, without running into the same
deployment problems that have hindered pairwise IDs.

-- Scott