...
The European Union is currently reviewing its data protection related legislation.
| Panel | ||
|---|---|---|
| ||
|
1. Objective of the Directive (Article 1)
...
2. Member States shall neither restrict nor prohibit the free flow of personal data between Member States for reasons connected with the protection afforded under paragraph 1.
2. Definition: Personal Data (Article 2a)
...
However, in a legal advice by DLA Piper [DLAPiper] to the eduGAIN project, it is recommended that all Attributes exchanged between Home Organisations and Service Providers are assumed to qualify as personal data. Even pseudonymised identifiers (such as, eduPersonTargetedID) and role Attributes (such as, eduPersonAffiliation) alone count as personal data because the end user’s Home Organisation can always link the Attributes back to the actual end user. Only Attributes that would be completely anonymised (i.e. when even the Home Organisation can no longer trace them back to the actual end user) will fall outside the scope of the Data protection directive.
3. Definition: Processing of Personal Data (Article 2b)
...
On the other hand, if the federation operator is also operating Identity Provider(s) on behalf of the Home Organisations, they are processing personal data. Therefore, they may have a data processor status, which is discussed next.
4. Definition: Data Controller and Processor (Article 2d,e)
...
Originally the distinction between the controller and processor was straightforward: controllers had independence in choosing how personal data were used; processors did not have any independence as they only did what they were asked to do by the Controller. However, in practice, various types of joint and sub-contracted activity are organized in ways that do not neatly fit that model.
4.1. Home organisation's position
...
If the Home Organisation has outsourced the operations of the Identity Provider (for instance, to the operator of the federation), then the operator of the Identity Provider may qualify as a data processor with regards to the Home Organisation.
4.2. Service Provider's position
...
The data protection directive is applied both to data controllers and processors, but the controller is held legally responsible also for the actions and omissions of the data processor. For instance, the controller is responsible for ensuring the security and informing the end user about the data processing. In an interfederation spanning multiple jurisdictions, it is also necessary to note that the jurisdiction follows the data controller.
4.3. Federation's position
In Section 3 it was assumed that the (inter)federation does not in general process personal data. However, in its legal advice to the eduGAIN project, DLA Piper [DLAPiper] took the view that the concept of “joint data controller” (see the previous section) may apply also to the federations and interfederations. This is possible because the federations and interfederations actually define the policy and the technical characteristics of the data exchange, regulate the rights, obligations and liability of the Home Organisations and Service Providers. Such tasks lean towards a qualification as data controller, because they can qualify as “essential means”.
5. Security of Processing (Article 17)
...
1. Member States shall prohibit the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life.
...
6. Purpose of Processing (Article 6.1b)
...
Following the directive, the institution must obey this purpose including when, acting as a Home Organisation, it releases Attributes to a Service Provider. The purpose of processing personal data in the Service Provider may not conflict with the purpose of processing in the Home Organisation. For example, a Home Organisation is not conflicting with the directive when releasing student's data to a Learning Management System in another university, but releasing students' personal data to a gambling service is hardly "supporting research and education".
7. Relevance of the Personal Data Processed (Article 6.1 c)
...
In an identity federation, the concept of an Attribute Release Policy (ARP, having its origins in the Shibboleth software) is commonly used for expressing which Attributes an Identity Provider releases to which Service Providers. For scalability reasons, in a large (inter)federation, some centralised mechanism to mediate Service Providers' Attribute Requirements to all Home Organisations and their Identity Providers is desirable. It can be assumed that the Service Provider is in a key role here; the Service Provider is the expert of the service.
8. Informing the Data Subject (Article 11)
...
In the Web Single Sign-On scenario of SAML 2.0, a convenient place to inform the end user is at the Home Organization before the Attribute release takes place for the first time. Several federations supporting the European higher education and research communities have already developed tools implementing this approach (e.g. the uApprove module implemented for Shibboleth, the consent module implemented for SimpleSAMLphp). This allows the user's decision to directly affect the transfer of Attributes to the Service Provider; if the Service Provider were communicating with the user it might have already received all the Attributes and values.
9. Criteria for Making Data Processing Legitimate (Article 7).
...
Historically, there seem to be two interpretations of this article. In some countries, consent has been the primary way of making data processing legitimate. In other countries, consent should be used only as a last resort, and the desirable way is to base processing of personal data on some other legal grounds whenever possible. To harmonise the use of consent as a legal basis for processing, the Article 29 Working Party has used an employment relationship as an example where consent may not be valid legal grounds. An employee is in a situation of dependence on the employer and might fear that he could be treated differently if he does not consent [WP29Consent, p.13].
9.1. Necessity legal grounds
...
In a legal advice provided to the eduGAIN project, DLA Piper [DLAPiper] recommends that, to avoid the difficult deduction if consent is valid legal basis, the Attribute release could rely always on the ‘legitimate interests’ legal grounds defined in Article 7.f. Unfortunately, there is some uncertainty in this, because it expects balancing the end user’s fundamental rights and freedoms and the data controller’s interests. Anyway, DLA Piper sees reliance on this legal grounds justified, taking into account the general privacy-protecting setup of the data flows in a federation, the low level of risk posed by the personal data being exchanged and the innocuous (mainly scientific) type of services accessed by the end users. This would also relieve the data controller from the practical issues relating to withdrawal of consent, and difficulties in managing the consent for children under the legal age.
9.2. Releasing optional extra Attributes on user consent
...
Finally, it is worth noting that consent does not override the other obligations imposed by the directive, including the purpose of processing, relevance of personal data processed and informing the data subject. It is wrong to assume that anything can be done with an end user's personal data if he consents to it.
10. Release of Personal Data to 3rd Countries
...
The European Commission publishes a list of countries with adequate level of protection. For instance, in Switzerland and Argentina, data protection laws ensure adequate level of protection. Canada has sector-specific data protection legislation, and the protection is adequate if the Canadian data controller is subject to the Personal Information Protection and Electronic Documents Act. In the United States, the level of data protection is adequate if the data controller is committed to the "Safe Harbor privacy principles" that the US Department of Commerce and the Commission have agreed on. Unfortunately, it appears that the universities do not belong to the jurisdiction of the US Department of Commerce and the Safe Harbour arrangement cannot be applied.
The Service Provider's jurisdiction follows the data controller. If the Service Provider is a data controller, the Service Provider's local laws on data protection are applied to the Service Provider. If the Service Provider is a data processor (i.e. processes personal data on behalf of the Home Organisation), the Home Organisation's laws are applied.
...
In a (inter)federation, direct contracts between Home Organisations and Service Providers are not expected in general, which suggests that this Code of Conduct alone cannot be used by Service Providers who are not bound to an adequate level of protection by the local law or the US Safe Harbour privacy principles. This does not exclude US exclude non-Europan Service Providers or even federations to receive Attributes from Home Organisations in EU/EEA, but their data protection issues must be solved using some other mechanism.
11. Receiving Personal Data from 3rd Countries
...
If the Home Organisation outside EU/EEA has a data controller/processor relationship with any of the Service Providers in EU/EEA, it needs a representative in EU/EEA. On the other hand, if the Service Provider in EU/EEA is a data processor for a non-EU Home Organisation, it needs to have a written agreement with the non-EU Home Organisation anyway (see section 4.), and the EU/EEA representative is covered there. In the (inter)federation agreement, the requirement for a non-EU/EEA Home Organisation having a representative in EU/EEA can be omitted. The Home Organisation does not need to reside in a country which guarantees adequate level of data protection.
12. The triangle of data protection relationships
...
- The user's and his/her Home Organization's relationship is covered by the Home Organisation’s AUP (acceptable use policy) agreement with the user.
- Typically, an emploee, student and other end user accepts the Home Organisation's AUP when he/she receives his/her user account.
- The Home Organisation has an opportunity to inform the user on his/her personal data processing when he/she accepts the AUP
- The user's and Service Provider's relationship is covered by the Service Provider’s privacy policy
- This Data protection Code of Conduct is proposed to cover the relationship between the Home organization and Service Provider.
- Additionally, the Home Organisation and Service Provider may have other agreements, such as a data processor/controller agreement. Those agreements are proposed to take precedence over the Code of Conduct.
...
13. EU laws factored to concrete requirements
In this section, the provisions presented above are factored into concrete design requirements for an (inter)federation. Where appropriate, this section also proposes a scalable division of responsibilities between the Home Organisation and Service Provider.
- General responsibilities of the Home Organisation and Service Provider
- The Home Organisation and Service Provider MUST take necessary measures to protect personal data, in particular when it is transmitted over a network.
- A Home Organisation cannot release Attributes to a Service Provider without "implement(ing) appropriate ... organizational measures" to ensure that the Attribute release doesn't result in unlawful processing.
- Minimal disclosure
- All Attributes exchanged between Home Organisations and Service Providers are assumed to qualify as personal data (including role Attributes, such as eduPersonAffiliation).
- A Service Provider MUST publish the list of Attributes that are adequate, relevant and not excessive to the Service.
- A Home Organisation MUST have confidence that all of the Attributes requested by the Service Provider are relevant to the service.
- A Home Organisation MUST release only the relevant Attributes to the Service Provider
- A Service Provider MUST lower the risk for all parties by
- deciding to request lower risk kinds of data (for example, eduPersonTargetedID instead of eduPersonPrincipalName).
- for multi-valued Attributes, indicating the subset of values it needs (for instance, eduPersonAffiliation="student", c.f. saml:AttributeValue).
...
[WP29Consent] Article 29 Working Party. Opinion on Consent. Available in httphttps://ec.europa.eu/justice/policiesarticle-29/privacydocumentation/docsopinion-recommendation/wpdocsfiles/2011/wp187_en.pdf