Shibboleth Developers

[Chad La Joie <>]

On 6/22/10 1:53 PM, Huneycutt, Karsten wrote:
> How about disabling the engine for entity groups (like attribute
> filter policies)?  This will allow us to group approved business
> applications (the campus portal, the ERP system, etc) under an entity
> group -- which may or may not be a good thing.

Yes.  Currently anywhere in the code where you can do something per-SP 
you can also put in an EntitiesDescriptor name and have that work too. 
That would continue here.

> Does it make any sense to whitelist attribute-value pairs per SP, so
> that an SP can know that someone has, say, ePA set to "member", but
> the user must consent to releasing the "student" value?  I'm not sure
> how widely that would be used.

This is another one of those things that people who want to some 
development and testing on their side could do.  As has been shown by 
the number of ideas raised with this there are lots of thoughts and I'm 
pretty sure they don't all fit together nicely, so I think more 
experimenting needs to be done.  We just have to get the first version 
out the door.  :)

> > - Ability to require user consent for every login or to only ask
> > again when the data (attribute values) to be sent to the SP
> > changes.
>
> Can this be set per-SP, with some timeout (every six months for SP x,
> every year for SP y)?  Or, perhaps, per-user, so that if a user has
> heightened privacy settings, we can trigger asking for consent on
> every login?  If you want to get even more granular, make the
> requirement for consent be calculated based on the value of another
> attribute or a script -- SP x is asking for your phone number, which
> you've marked as private, and for your name, which is public -- you
> must consent to the release of your phone number each time, but not
> necessarily your name unless it's changed.

Same answer as above.

> "only ask again when the data to be sent to the SP changes" implies
> that this will keep a shadow copy of the user's attributes.  If that
> will be the case, that seems inefficient, and many of us already have
> systems that can notify/take action when an attribute value changes.
> Can we have a way to let that decision be made by that system and NOT
> keep a shadow copy on the IdP consent engine?

No, not a copy, it just hashes the values.  If you want to write code to 
reflect your businesses processes (i.e. expire consent every 6 months) 
you can do that.  There will be public APIs to call in to.

--
Chad La Joie
http://itumi.biz
trusted identities, delivered