Please note this is a summary of the reasoning behind approaches taken to attribute release by federations, with particular reference to the REFEDS Research and Scholarship Entity Category. It does not constitute legal advice but does point to legal documentation that can be used to support the ideas in this process. All federations and organisations should take appropriate legal advice but are free to use this information to support arguments and processes. For more information see: https://refeds.org/research-and-scholarship
With thanks to Andrew Cormack for allowing REFEDS to use his material for this advice piece.
Any organisation that processes personal data needs to have a legal justification for doing so. Personal data is defined in GDPR as "information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person."
Practically speaking this may mean government id card information, computer IP address, social media account name as well as personal name, telephone, address etc. The Research and Scholarship Entity Category recommended by REFEDS supports minimal disclosure of a few elements of personal data to support access to resources (an identifier, name, email address).
There are 6 use-cases in which you can share personal data within the EU. These remain the same from the pre-GDPR Directive and within the GDPR (Article 6).
Short Name used by REFEDS
The data subject has unambiguously given his consent.
Consent must be unambiguous – forcing people to tick boxes for access can be seen as forced consent.
Processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract.
Limited cases where the data subject is legitimately required by contract to provide personal data.
Processing is necessary for compliance with a legal obligation to which the data controller is subject.
Unlikely to apply in REFEDS scenarios.
Processing is necessary in order to protect the vital interests of the data subject.
Unlikely to apply in REFEDS scenarios.
Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the data are disclosed.
Unlikely to apply in REFEDS scenarios.
Processing is necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed.
Can be claimed that legitimate interest exists where users need to give certain pieces of data to use a tool for their study / work.
Only three of these options would have bearing in the typical exchanges within a research and education identity federation: consent, contractual and legitimate interests.
Work has been done on consent modules for access management workflows and it is now easier to build this functionality in to user screens, but there are concerns that in many scenarios consent could be seen as forced as the subject has no choice but to pass the information if they want to use the resource. The Article 29 Working Party warn that consent may be a "false good solution". This is strengthened in the text of the GDPR, which is clear that consent must be freely given (Article 7).
"Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement." (Recital 32).
The important text here is that release must be in line with the performance of a contract to which the data subject is a party. It could be argued that for some staff members, accessing services using federated identities could be seen as a function that is required by their job role but this is difficult to assert for all scenarios. The argument would be much more difficult for students and researchers.
The Research and Scholarship Entity Category relies on the legitimate interest approach. This is supported by the Article 29 WP Opinion on Legitimate Interests documentation. There has been some concern expressed that Legitimate Interests cannot be used for Public Authorities as in some countries universities and colleges are deemed Public Authorities, but this limitation is only related to activities that directly relate to work that directly relates to the "public" aspects of the worn undertaken by that organisation. A student accessing a scholarly article or the typical day to day work of a researcher would not fall under the "public" aspects of the organisation. There is a useful article detailing how this has been addressed in the UK.
The Article 29 WP recognises that:
"The current text of Article 7(f) of the Directive is open ended. This flexible wording leaves much room for interpretation and has sometimes as experience has shown led to lack of predictability and lack of legal certainty. However, if used in the right context, and with the application of the right criteria, as set out in this Opinion, Article 7(f) has an essential role to play as a legal ground for legitimate data processing."
The Article 29 WP states that:
"...an appropriate assessment of the balance under Article 7(f), often with an opportunity to opt-out of the processing, may in other cases be a valid alternative to inappropriate use of, for instance, the ground of 'consent' or 'necessity for the performance of a contract'. Considered in this way, Article 7(f) presents complementary safeguards - which require appropriate measures - compared to the other pre-determined grounds. (p10)".
The text of the GDPR makes a stronger case for the use of Legitimate Interests. This is described in Recitals 47 - 49.
In outlining the use case for using Legitimate Interests, the GDPR states that:
"Such legitimate interest could exist for example where there is a relevant and appropriate relationship between the data subject and the controller in situations such as where the data subject is a client or in the service of the controller." (Recital 47)
This description applies well to most transactions carried out by services within Identity Federations, particularly with the added safeguard of R&S. However, the GDPR insists that there must be a careful assessment of legitimate interests before that purpose is used. The following table shows some areas that should be used to make this assessment, and demonstrates how the R&S Entity Category can help organisations make this determination. The GÉANT Code of Conduct also has some useful information on good practice for home organisations.
|Issue||Discussion||Review of R&S|
|Put in Place Safeguards||Data minimisation (necessary), privacy enhancing technologies (for example pseudonyms), transparency and a right to opt-out.|
R&S addresses all of these areas. The Code of Conduct also has information on necessary attributes.
We'd also recommend reviewing the Privacy Notice of an SP and encouraging them to populate privacy statement URL in metadata.
|Balance the Rights of Data Subjects and the Rights of Data Controllers||Ensures the necessary flexibility for data controllers for situations where there is no undue impact on data subjects, while at the same time providing sufficient legal certainty and guarantees to data subjects that this open-ended provision will not be misused. The stronger the legitimate interest being pursued by the data controller and the less harm the processing does to the interests of the data subject, the greater the likelihood that the activity will be lawful.||R&S addresses this by limiting the types of services that are allowed to claim this category and focusing on low-risk services that have a clearly identifiable need for personal information such as wikis etc.|
|Impact Management||Impact on the individual will depend on the nature of the personal information, how it is processed and what the individual would reasonably expect.||Controlled in the R&S use case by minimal attribute sets and stress on the concept that attribute must not be asked for if it is not needed.|
|Define the "legitimate" reasons?||Norms in the community concerned falls in to this definition, as does the idea of both parties wishing to provide and receive access. Those claiming legitimate interest should be able to explain their interest and how it satisfies this balancing test||R&S provides this reason in its definition to support the process and to ensure that release is happening against an agreed set of criteria.|
|Ensure Transparency||Relying on legitimate interests still means users have to be informed about what their personal information is being used for. Privacy notices should still be put in place by IdPs and SPs.||Transparency is provided by keeping lists of SPs in this category and clear descriptions of what is being released.|
|Case-by-Case||Legitimacy must be ensured for each service.||Each SP is considered on a case-by-case basis by the federation in question and reviewed annually.|
In order to meet the requirements of the Legitimate Interests, the Article29WP suggests using the following balance test. The onus is on each home organisation / identity provider to carry out the balance test, but using R&S effectively helps organisations "pre-fill" this in. Whilst legitimacy must be ensured for each service, we suggest that organisations only need to carry out the balance test once for all R&S services as the services are vetted both at Federation level and in an annual audit by REFEDS.
Assessing which legal ground may potentially apply under Article 6.
Qualifying an interest as 'legitimate' or ‘illegitimate’.
Federations should pre-check these criteria when allowing a Service Provider the R&S tag.
Determining whether the processing is necessary to achieve the interest pursued.
Given the minimal data allowed to flow as part of R&S, it is unlikely that a less invasive approach would be found.
Establishing a provisional balance by assessing whether the data controller’s interest is overridden by the fundamental rights or interests of the data subjects.
As Service Providers must meet the definition of an R&S entity as described in the entity category, these conditions should be met.
Establishing a final balance by taking into account additional safeguards.
The design of identity federations and the privacy-by-design and data minimisation processes used in R&S meet these requirements.
Demonstrate compliance and ensure transparency.
Federations, Service Providers and Identity Providers are encouraged to document their usage of R&S in an appropriate public space.
What if the data subject exercises his/her right to object?
Identity Providers need to be able to demonstrate a mechanism for users to opt-out of data release. This can include scenarios where users lose access to the service.
The GDPR claims that it should be followed by "controllers and processors in the Union" (Recital 22) and controllers and processors "processing the data of data subjects who are in the Union" (Recital 23), although it is not clear how organisations outside of the EU will be made to comply with the requirements. This means the requirements of the GDPR impact nearly all participants in Identity Federation, as most will have some users accessing services within the EU. Where transfers are happening outside of the EU, the GDPR allows for this to happen under one of three possible headings:
Countries and processes covered by an adequacy decision are clearly defined and documented. At the time of writing these countries are: Andorra, Argentina, Canada (commercial organisations), Faroe Islands, Guernsey, Israel, Isle of Man, Jersey, New Zealand, Switzerland, Uruguay and the
US (limited to the Privacy Shield framework). Transfers to these countries can be made using the same criteria as any EU country. Since July 2020, the US Privacy Shield has been determined invalid for international transfers.
Article 46 sets out a series of safeguards that can be used to permit transfer to a third country or international organisation. These are:
Of these, only the Code of Conduct approach is used significantly at this point in time in our community. Guidelines are being developed for the use of Binding Corporate Rules and Certification but it may be some time before they can be practically used by organisations.
GÉANT is exploring a Code of Conduct that can be used at international scale. This could be used in conjunction with R&S to support data transfer to third countries and international organisations. As things currently stand, the Dutch Data Protection Authority has declared that it will not be possible to have a Code of Conduct for GÉANT that covers both EU transfers and non-EU transfers.
REFEDS is actively following guidelines on Certification to see if R&S can be consider a certification approach in the future. This is likely to be a lengthy process.
The Article 29 Working Party have provide guidelines for the use of derogation under Article 49. The Article lists a series of potential derogations that could be used for transfer, but many of these will not prove adequate for federated access management.
Use of legitimate interests as a derogation for federated access management exchanges to third countries does meet many of the obligations:
It is likely that this area will be subject to much debate and discussion in coming months as GDPR is implemented. Given the lack of maturity of approaches under Article 46 (safeguards), the demonstrable application of safeguards and privacy via R&S and the high-risk impact of other solutions by the user (using commercial logins) there is a strong case to continue using R&S in these scenarios.