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 for scalableattribute 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 2.4 documentation.

Service Categories for Attribute Release

Inspired by prior work by RENATER the international the academic Identity Federations community (lead by by InCommon, REFEDS and GEANTGÉ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 individual services on 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 services 's requests for service access on a case-by-case basis creates too much work for institutions and their staff (if done "right"), often resulting in students or scholars not being able to access needed (inter-)federated resources because the institiutional SAML Identity Provider did does not release any data 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 v2.4 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 ultimately responsible for decisions resulting in the (non-)release of personal data to third parties. Contact ACOnet with any and all questions relating to regarding Service Categories!

REFEDS Research & Scholarship

Membership in the category REFEDS R&S is reserved to services "that support are operated for the purpose of supporting research and scholarship interaction, collaboration or management as an essential component, at least in part". This globally applicable category takes a risk-based approach to enabling access to high-benefit/low-risk services, releasing only low-risk personal data. Basically only the minimum personal data required for scientific collaboration and attribution of a person's work is released (name, email address and an identifer).

<afp:AttributeFilterPolicy id="REFEDSResearchAndScholarship">
  <afp:PolicyRequirementRule xsi:type="saml:AttributeRequesterEntityAttributeExactMatch"
    attributeName="http://macedir.org/entity-category"
    attributeValue="http://refeds.org/category/research-and-scholarship"/>
 
  <!-- minimal subset of the R&S attribute bundle -->
  <!-- assuming non-reassigned ePPN values, otherwise also include persistentId/eduPersonTargetedID here -->
  <afp:AttributeRule attributeID="eduPersonPrincipalName">
    <afp:PermitValueRule xsi:type="basic:ANY" />
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="email">
    <afp:PermitValueRule xsi:type="basic:ANY" />
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="displayName">
    <afp:PermitValueRule xsi:type="basic:ANY" />
  </afp:AttributeRule>

  <!-- other attributes only if requested -->
  <afp:AttributeRule attributeID="givenName">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="surname">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="eduPersonTargetedID">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
</afp:AttributeFilterPolicy>

GEANT EU/EEA Data Protection Code of Conduct

GÉANT Data Protection Code of Conduct

As part of the GÉANT Data Protection Code of Conduct's As part of the Code of Conduct Cookbook you'll find the Recipe for a Home Organisation, giving providing complete instructions on the steps necessary steps for deployment. This Service Category only applies when both the Service Provider and  (as well as the Identity Provider are , which trivially will be case for all eduID.at Identity Providers) is based in the EU/EEA (i.e., it does not help with services outside the EU/EEA) and uses the EU data protection directive or countries with adequate data protection and uses the EU Data Protection Directive 95/46/EC as common frame for disparate implementations thereof throughout the EU. As such it is mostly meant as a reminder and a reassurance to both service owners and home organizations that the services covered are already subject to (national implementations of) EU data protection law.

As this Category definition does not specify an attribute bundle (i.e., it doesn't reference specific one set of  attributes which should be released to all category members) the list set of attributes to release is basically open-ended. As such you may need to adapt the attribute rules included within the policy, possibly including (fewer or) more attributes (depending on what attributes you have available in your IDP and whether the institution is willing to release them under these terms). 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 very 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. Service Providers requesting less data would also recieve less data (but can still be covered by this policy rule).

<afp:AttributeFilterPolicy id="GeantEEADataProtectionCodeOfConduct">
  <afp:PolicyRequirementRule xsi:type="saml:AttributeRequesterEntityAttributeExactMatch"
    attributeName="http://macedir.org/entity-category"
    attributeValue="http://www.geant.net/uri/dataprotection-code-of-conduct/v1"/>
  <!-- Release data to EU CoCo-SPs, based on RequestedAttributes in SAML metadata -->
  <afp:AttributeRule attributeID="displayName">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="givenName">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="surname">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="email">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="eduPersonPrincipalName">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="eduPersonTargetedID">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="schacHomeOrganization">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </afp:AttributeRule>
</afp:AttributeFilterPolicy>

Again, be sure to check out the more general attribute release documentation in our Shibboleth IDP documentation, which contains more ready-to-use examples and approaches.

European Student Identifier

As part of the European Commission's work in the context of the Erasmus+ programme (Student Mobility, Erasmus Without Paper/EWP, etc.) a data structure called the European Student Identifier (ESI) has been defined. Unfortunately it wasn't designed in a way that would allow Service Providers to request it from Identity Providers using standard methods provided by SAML 2.0 Metadata (via the RequestedAttribute element). So in order to enable its scalable use across Europe additional specification work was required. The benefit of that additional specification work is that there now exists a lightweight framework to control the scalable and secure release of the ESI (and related data), governing what Service Providers should be eligible to request and consequently receive this data from academic institutions such as those participating in eduID.at and eduGAIN.

We're also using this category to control release of the Erasmus Without Paper (EWP) admin entitlement to keep things simple:

Again, be sure to check out the more general attribute release documentation in our Shibboleth IDP documentation, which contains more ready-to-use examples and approachesSee also Attribute release, from our  Shibboleth IDP 2.4 documentation section.