How do we verify students?
The InAcademia Service is specifically provided for validating a user’s affiliation with academia. It can validate if a user is a student, a member of staff or faculty. To validate student and other affiliations, InAcademia uses the information provided by the home institution (University) of the user. InAcademia leverages information from all of Higher Education throughout Europe via the interfederation service, eduGAIN. Validation is real time, the information is up-to-date, and the identity of the user has been thoroughly verified (by the academic institution), e.g. by validating the user’s national ID or similar.
A validation request is initiated at a merchant’s website when a user clicks the InAcademia button. This triggers a validation request at the InAcademia.org service endpoint. The user is then asked by InAcademia.org to prove affiliation with the academic community by entering their institution-specific credentials. InAcademia evaluates if the response matches the requested affiliation and sends back the result to the requesting merchant.
Validation Profiles
Upon request by the merchant, two profiles of the user are available:
- ‘Transient´ profile. When using this profile, the response will contain nothing that can be used to identify or profile the user persistently.
- ‘Persistent’ profile. When using this profile, the response will contain a pseudonymous identifier. This identifier has no relation with the identifier(s) provided by the home institution. The identifier will remain the same across multiple requests for the same user by the same merchant. Different merchants will receive different pseudonymous identifiers.
The user’s affiliation is always sent to the requesting merchant. However, a merchant may only request a specific affiliation.
Supported Affiliation Types
affiliated = Is the end-user affiliated to the institution?
student = Is the end-user a student at the institution?
faculty+staff = Is the end-user a teacher/researcher (faculty) or a worker (other than teacher/researcher, staff) at the institution?
alum = Is the end-user an alumni at the institution?
Supported Claim Types
The response may also contain additional claims, including the country of the user and the domain name of the institution, should an institution be willing and able to provide this.
country = The country of the users’ home institution.
domain = The domain name of the users’ home institution.
In all cases the user is presented with a consent screen, allowing the user the option not to pass certain information to the requesting merchant. Do note that not passing requested information may lead to a failure of the validation and is signaled to the merchant as such.
The InAcademia Service is set up as a ‘token translation service’, translating SAML2 attribute values on one side to a boolean value for use with another protocol on the other side. Although all sorts of protocols would be possible (OpenID Connect, REST API + oAuth2, OpenID and even SAML2), currently the service provides an OpenID Connect interface for merchants.
The image below provides a schematic overview of the core components, protocols and flows involved. Note that the REST based API only validates student or staff membership and therefore does not carry any personal information. The service API is shielded with OpenID Connect, using the implicit grant scheme, which requires a user to authenticate and consent before a response is passed back to InAcademia. For user authentication, InAcademia uses the Identity Providers as provided via eduGAIN, the pan European interfederation for Research and Education.