InAcademia and Privacy

As a service that has been designed from the outset to be privacy preserving, InAcademia doesn’t request any personally identifiable information from the merchant about any individual that uses InAcademia in the process of validating its affiliation to an institution. 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 (”the Service”) offering for the end user (an individual affiliated with an academic institution as “student”, “staff”, “faculty”, “employee” or “member”), a mechanism to prove to a merchant website (e.g. web shop) that they are entitled to the services, discounts or special offers on the basis of a positive verification of their affiliation with an academic institution.

How does the InAcademia Service work?

When the end user visits a participating merchant’s website, the merchant may have embedded the InAcademia service into its own validation workflow, or the user might find an InAcademia button. The validation of the end user affiliation by the merchant is initiated by the user, inside the merchant’s web domain, and triggers an OIDC request towards the InAcademia OpenID Provider (OP). In order to proceed with the validation of the end user affiliation (“student”, “staff”, “faculty”, “employee” or “member”), the end user is redirected to their institution website using the OIDC protocol and an ‘IdP hint’ claim inside the request, or via a discovery service in eduGAIN, which instructs the InAcademia OP to initiate a SAML request to the specified institution. This process will be familiar to users that benefit from eduGAIN and/or national identity federation membership via their institution, as this is a similar process as utilised in login processes for many academic services. The request to validate the end user affiliation contains a state value (identifying the session between InAcademia and the system of the institution) and a nonce value (which should both be randomly produced values) an identifier for the institution (the IdP hint) and does not contain any personally identifiable information. The user is invited to authenticate with the institution’s SAML Identity Provider (IdP). The data provided by the end user for validation of their affiliation with the institution are processed directly by the home institution (the institution is the data controller of the credentials and this data is not visible to or processed by InAcademia).

Upon successful authentication, the Institution’s IdP constructs a SAML response to the InAcademia Service, releasing the requested attributes. The SAML response will contain the state value, the affiliation attribute values, such as “student”, “staff”, “faculty”, “employee” or “member”, if one exists, and either a transient or persistent identifier. The InAcademia Service will then evaluate the affiliation received from the institution, to assess whether it matches the affiliation to be validated:

a) If the affiliation value provided by the institution matches the requested affiliation, InAcademia will signal to the merchant a successful affiliation validation was made. Upon request of the merchant, InAcademia may return either a pseudonymised transient or pseudonymised persistent identifier, and may confirm either the domain or federated entityID of the institution as part of this confirmation (and in this case the end user will get access to the special offers/discounts) inside an encrypted ID Token,

b) If the affiliation value provided does not match the requested affiliation, InAcademia will signal the merchant that the affiliation validation has failed including an error message specific to the reason of failure. No ID Token or additional data or identifiers are sent to the merchant as part of negative transaction (in such case the end user will not get access to the special offers/discounts).

The result of the validation is returned to the merchant in an OIDC response along with the state value on the basis of the end user confirming its consent to do so.

Data flows and processes

InAcademia/GÉANT

The GÉANT Association (licensor of the InAcademia Service) is the data controller of the validation result and the technical log containing the following data (which are stored in EEA and only for limited period of 28 days):

• The date and time of the transaction;
• A session identifier for the merchant which requested the validation;
• An identifier for the merchant;
• A session identifier as provided by the institution;
• The affiliation and any further information provided by the Institution (in case of positive validation – including the country and name of your institution or in case of negative validation – simple no);
• The transient or persistent identifier
• The IP address used at the time of the transaction.

Merchant role

The merchant is the Controller of the user’s personal information registered with the merchant during the registration and sales process. However, the OIDC transaction does not request or include the user’s personal information. The user is redirected via the InAcademia Service by way of 1) the merchant having configured the idp_hint value behind the institution selection process in its web UI, or 2) the merchant having configured a redirect to the InAcademia Discovery Service. Because it uses the OIDC and SAML protocols, the transaction itself is unaware of the user’s personal information, and is maintained only by the state and nonce.

Institution role

The institution is the Controller of the users' personal information registered with the institution. The SAML transaction ensures that none of the user's credentials are visible or transferred to InAcademia by the end user to validate their affiliation (only the act of authenticating allows the IdP to release the required attributes which are described in the InAcademia Privacy Statement); this data is processed by the institution for the purpose of the authenticating the end user and is outside the scope of the InAcademia service.

The SAML response from the Institution’s IdP contains the affiliation attribute, such as “student”, “staff”, “faculty”, “employee” or “member”, if one exists, the state value and either a transient or persistent identifier, as well as a transaction identifier.

The SAML response from the institution’s IdP is processed by the InAcademia Service to create an OIDC response to the merchant. The OIDC response provides the value of the affiliation attribute to the merchant. Where the merchant requests a transient identifier, InAcademia creates a pseudonymised transient identifier. Where the merchant requests a persistent identifier, InAcademia creates a pseudonymised persistent identifier and does not release the values received from the institution's identity provider. The pseudonymised identifiers cannot be translated by the merchant.