Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
iconfalse

REFEDS has published guidance on justification for attribute release, especially with regard to the use of Service Categories (or Entity Categories) and the "REFEDS Research & Scholarship" category in particular.

See also IDP2 Attribute release, in our  Shibboleth IDP 2.4 documentation.

...

Inspired by prior work by RENATER, the international Identity Federations community (lead by InCommonREFEDS 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: It has long been apparent that manually writing and maintaining attribute release rules based 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 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 not release any data to the accessed service.

...

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 Service Categories!

REFEDS Research & Scholarship

Membership in the category REFEDS R&S is reserved to services "that support research and scholarship interaction, collaboration or management as an essential component". 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).

...

Expand
titleShow example Shibboleth IDP policy for REFEDS R&S:
Code Block
languagehtml/xml
<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 and S" attribute bundle. -->
  <!-- If ePPN values could be reassigned you MUST also release eduPersonTargetedID -->
  <afp:AttributeRule attributeID="eduPersonPrincipalName">
    <afp:PermitValueRule xsi:type="basic:ANY" />
  </afp:AttributeRule>
  <afp:AttributeRule attributeID="eduPersonTargetedID">
    <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="false"/>
  </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 (could also be released unconditionally) -->
  <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:AttributeFilterPolicy>

...

GÉANT Data Protection Code of Conduct

As part of the GÉANT Data Protection Code of Conduct's Cookbook you'll find the Recipe for a Home Organisation, giving complete instructions on the necessary steps for deployment. This Service Category only applies when both the Service Provider and the Identity Provider are 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.

Info
iconfalse

GEANT GÉANT Data Protection Code of Conduct is legislation-limited: Only services from specific legislations may carry this category, and only if they submit themselfs to the GEANT GÉANT Data Protection Code of Conduct and all its requirements.

As this Category definition does not currently specify an attribute bundle (i.e., it doesn't reference specific attributes which should be released) the list 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). In practice, however, only a very limited set of data is being exchanged within/across academic Identity Federations today: A person's name, email-address, identifier(s) and role infomation (e.g. "student" vs. "staff").
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.

Expand
titleShow example Shibboleth IDP policy for GEANT EU Code of Conduct:
Code Block
languagehtml/xml
<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>

 

See also IDP2 Attribute release, from our  Shibboleth IDP 2.4 documentation section.