Service Categories (or Entity Categories) help managing the secure release of the right attributes to only appropriate Service Providers – within the eduID.at federation and beyond. As such the The use of the Service Categories within local policies is highly recommended as basis documented below constitutes global Best Current Practices for controlled and scalable attribute release policies/decisions. The ultimate responsibility for the release of any personal data to third parties under these terms rests with the institution releasing the data, though.

See also Attribute release in our our Shibboleth IDP v3 documentation.

Service Categories for Attribute Release

Inspired by prior work by RENATER, the international Identity Federations community (lead by InCommon, REFEDS and GÉANT/eduGAIN) has started to create Service Categories (technically called "Entity Categories", since they apply to SAML "entities") in order to ease the management of release of personal data ("attributes") to services within and across large-scale multi-party federations: It has long been apparent that manually writing and maintaining attribute release rules based on individualon individual services does not scale sufficiently, esp. taking into account that e-research today requires international collaboration and does not stop at national or "federation" borders. Dealing with individual requests to access services on a case-by-case basis creates too much work for institutions and their staff, often resulting in students or scholars not being able to access needed (inter-)federated resources because the institiutional SAML Identity Provider did not release the needed attributes to the accessed service.

...

Below you'll find copy&paste-able attribute release filter rules for the widely used Shibboleth Identity Provider v3 for  software for each of the most important Service Categories. Be sure to carefully read and understand each category's description/definition before use.

...

People managing technical infrastructure (such as servers and Shibboleth configuration files) should not be responsible for decisions resulting in the (non-)release of personal data to third parties. Contact ACOnet with any questions relating to regarding Service Categories!

REFEDS Research & Scholarship

...

...

As this Category definition does not specify an attribute bundle (i.e., it doesn't reference one set of  attributes which should be released to all category members) the set of attributes to be released may vary from service to service. The data to transmit under this category is limited to attributes "that are necessary for enabling access to the service provided by the Service Provider" (2.b, "purpose limitation"), though. In practice only a limited set of data will be exchanged within/across academic Identity Federations today: That could include a person's name, email address, identifier(s) and role infomation ("affiliation", such as "student" or "staff"), but could also be less than that if the service needs less data to perform appropriate access control.
The confguration below is an example based on the most commonly used attributes in Identity Federations today which most/all eduID.at Identity Providers should be able to generate. I..e, this constitutes the upper limit of what an IDP would release to Service Providers requesting data under the GÉANT Data Protection Code of Conduct category.

...