Shibboleth Developers

[Chad La Joie <>]

On 6/10/10 10:01 AM, 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).
>
> 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.

Yeah, I understood your reason for asking.  In some ways it's really a 
no-win situation.  A lot of people are comfortable throwing up a 
database of some sort but DBs are really hard to make resilient to 
failures without paying people like IBM and Oracle lots of money. 
People are less comfortable setting up or changing their LDAP but LDAP 
directories are relatively easy to make resilient (even though an 
astounding number of people don't do this).  The clustering solution 
we're looking at is easy to deploy, is resilient by definition, and 
doesn't require people to really do anything but you lose any sort of 
general query language like SQL and LDAP filters with which you might do 
reporting.
--
Chad La Joie
http://itumi.biz
trusted identities, delivered