Advice from federation operators that have already implemented R&S is available. REFEDS has also prepared guidance on the legal justification for R&S and a presentation that can be reused for local training (cf. training material from the Attribute Release Workshop for Federation Operators, TNC2015). If you would like help to provide training for your members please do not hesitate to contact us.
What do I do if I think a Service Provider is misusing R&S?
Please either contact your local Federation Operator or the REFED Steering Committee (email@example.com). The REFEDS SC has a process in place for reviewing such complaints and working with Federation Operators to address.
For SP Owners
What types of services are considered R&S services?
Service Providers should only request attributes that the service actually uses, so for example if email address is not required by the service it should not be requested. The specification does not explicitly prevent Service Providers from requesting attributes outside the R&S attribute bundle. R&S works best for both Identity Providers and Service Providers when the bundle is treated as the maximal set of attributes requested. The specification gives the following advice:
Service Providers should reference the eduPerson specification for details on values that may be received per attribute, but in general terms:
- eduPersonPrincipalName, eduPersonTargetedID, displayName are single-valued.
givenNamegivenName + sn sn, email address, eduPersonScopedAffiliation can be mutli-valued.
For IdP Operators
have to be released by an R&S IdP?
The Research & Scholarship specification defines a bundles of attributes that Identity Providers are encouraged to supporting R&S must release to R&S services:
- personal identifiers: email address, person name (either displayName or givenName+sn; ideally both forms to help applications that can only deal with one form), eduPersonPrincipalName
- If eduPersonPrincipalName
- pseudonymous identifier: eduPersonTargetedID
- affiliation: eduPersonScopedAffiliationvalues may be re-assigend at a given IdP (from one person to another, even after a grace period) a SAML 2.0 persistent NameID (or eduPersonTargetedId attribute, though deprecated) must also be released by that IdP.
(Persistent NameIDs may not be re-assigned, so R&S SPs that
The bundle also includes one optional attribute (everything else above being mandated by the specification):
Service Providers should therefore be prepared to not receive affiliation attributes under R&S, due to their optional nature.
Affiliations in the form of eduPersonScopedAffiliation attribute values have long known to be not widely interoperable (REFEDS Whitepaper, A.Cormack, M.Linden, 2009) particularly in cross-institutional, cross-cultural or international uses. (As pointed out in the conclusion of said whitepaper affiliations are also unsuitable for most kinds of authorization use-cases, them being too "high level"). For these reasons their use within R&S is not emphasized or recommended.
Category support is defined as follows:
Finally, consider the following counterexample. Suppose an IdP releases the minimal subset of the R&S attribute bundle to any R&S SP provided the user is a non-student. That IdP may indeed receive the REFEDS R&S entity attribute in its metadata since it supports the R&S category "for some a significant subset of the Identity Provider's its user population," as required by the REFEDS R&S specification.
Some tips and suggestions for implementing the Research & Scholarship Category are given in a separate document. There is also guidance and advice on attribute release and a useful seven step programme that could be used when adding service providers to an entity category.