By factoring out the attribute filtering process out of CASImpl, support could be made available via custom injection of filters that would do more other than making sure a registered service received the right set of allowed attributes.
The filters would work in sequence as part of a chain, where the resultset would be continually passed down the chain for further refinement. filters would be implemented to make sure an attribute value for instance has the proper length, format, is consistent with custom authZ rule, etc.
For example, one Registered Service might be allowed to see values of a particular course-related attribute that apply to undergraduate engineeringstudents. Another service might be allowed to see the same attribute, but only for values that apply to medical students. To do so, the entire CASImpl class needs to be overlayed. custom filters would ease this configuration.