As a service that has been designed from the outset to be privacy preserving, InAcademia doesn’t actually store any data about any individual that requires validation. This page describes the data and information flow resulting from a validation request (Student is used throughout for simplicity but the process is identical for each user type)
InAcademia is an affiliation validation service (”Service”) offering for the end user (individual affiliated with academic institution as “student”, “staff”, “faculty”, “member” or “affiliated”), whom is visiting merchant website (e.g. web shop) additional discounts or special offers on the basis of the positive verification of the end user affiliation with their academic institution.
How does the InAcademia Service work?
When the end user visits a participating merchant’s website, they will find an InAcademia button – which will allow to the end user to obtain special offers/discounts on the basis of the positive result of verification with an academic institution.
The validation of the end user affiliation by the merchant will only happen upon the end user request, when the InAcademia button will be chosen. In order to proceed with the validation of the end user affiliation (“student”, “staff”, “faculty”, “member” or “affiliated”), the end user will be redirected to their institution website. The data provided by the end user for the validation of the affiliation with their institution are processed directly by this institution (the institution is the data controller of the credentials and this data is not processed by InAcademia). The request to validate the end user affiliation within InAcademia does not contain any personal data.
The InAcademia Service asks the end user to authenticate with their institution and the institution will provide InAcademia with the following information: the affiliation to the institution (“student”, “staff”, “faculty”, “member” or “affiliated”) and the persistent identifier identifying the session between InAcademia and the system of the institution.
Upon successful authentication, InAcademia will evaluate the affiliation received from the institution:
a) If the affiliation provided by the institution matches the requested validation, InAcademia will signal to the merchant a successful affiliation validation was made. Upon request of the merchant, InAcademia may send a persistent identifier, the country and name of the institution as part of this confirmation (and in this case the end user will get access to the special offers/discounts),
b) If the affiliation provided does not match the requested affiliation, InAcademia will signal the merchant that the affiliation validation has failed. No additional data is sent to the merchant as part of such a transaction (in such case the end user will not get access to the special offers/discounts).
The result of the validation is sent to the merchant on the basis of the end user consent.
Data flows and processes
- The date and time of your transaction;
- A session identifier for the merchant which requested the validation;
- An identifier for the merchant;
- A session identifier as provided by your institution;
- The affiliation provided by your Institution (in case of positive validation – including the country and name of your institution or in case of negative validation – simple no);
- The IP address used at the time of the transaction.
Analysing data flow, there must be taken into account two distinct situations:
- Where the Merchant is in possession of the identity of the end user (as it may have in an online store involving a registration process). In this case, it should be analysed as to whether or not there is personal data being processed by InAcademia for the Merchant. And the first issue is whether, in the hands of a Merchant the transaction id can be considered as “personal data”. In line with the GDPR ‘personal data’ is any information relating to an identified or identifiable natural person (‘data subject’); whilst it could be argued that the transaction id is “information” and in the hands of the Merchant it may well therefore be personal data. However, there is no flow of any more meaningful data from the Merchant to InAcademia (in either scenario) and in the hands of InAcademia (with no power whatsoever to link the id to anything in the hands of the Merchant) it is passive. The issue of dynamic IP addresses was recently considered by the Court of Justice of the European Union (“CJEU”) (Breyer v Bundesrepublik Deutschland, 2016). The CJEU ruled that dynamic IP addresses may constitute ‘personal data’ where only a third party (in that case an internet service provider; in this case: the Merchant) has additional data necessary to identify the individual. However, this would not be the case if the identification of the data subject was practically impossible. It is “practically impossible” for the transaction id to be used to identify an individual.
- What needs to be taken into account is whether validation result (yes/no) can be associated by the Merchant with the transaction id – and what is possible in the scenario above that allows to the Merchant link transaction id with the specific end user.
- Taking into account the above mentioned, Merchant is data controller of the validation result of InAcademia Service and GÉANT (InAcademia Service) is acting as data processor of this piece of data – hence, adequate DPA provisions are contained in the Agreement between the Merchant and GÉANT.
Additionally, the institution is the controller of the data provided by the end user to validate their affiliation and this data are processed by the institution for the purpose of the authenticating the end user, what is in line with the original purpose of the processing of the end user personal data by the institution.
What is provided to InAcademia as the result of the end user self-authentication with their home institution is the transaction id, that itself does not allow to identify the end user by InAcademia (hence does not constitute personal data and does not require any additional DPA).
The transaction id can be used to identify the end user only by the Merchant and only in the second scenario described above (when Merchant has more data about the end user) and there are appropriate DPA provisions in the contract between InAcademia and Merchant.