Grouper Developers Forum

[Tom Barton <>]

Niels van Dijk wrote:
> But my question is why would one want to still provide membership of a
> group, after the ttl has expired? I can image I'd like to be able to
> inform a user of the fact that his membership is about to be terminated,
> but I also think that in that case the groupmembership itself should no
> longer be provided by grouper at the moment the memebership ends.
> Feature 12 touches this as well I think. The current description of both
> items suggest to me that it may become the implementing parties role to
> check if a membership or attribute is still 'valid'. I strongly feel
> that is the task of the group membership system, as the group management
> system and the implementing party may decide to implement a different
> set of validation rules.

I think that only the private side of the grouper api (facing the 
database) would need to be modified to check ttl. The existing public 
api would still only present current memberships. Right Chris? Of 
course, there will be enhancements to the public api to enable clients 
to manage or monitor ttls and other attributes.

> Another thing I was wondering is if there is a usecase in which group
> related attribute enrichment or aggregation might take place, as is
> currently possible in identity federations. If so, will/should this for
> example be reflected in the attribute namespace discussion?

I also anticipate this and commented in email about it. Perhaps that 
should be reflected in the wiki page, amid the attribute namespace stuff 
that also needs to be added.

Tom