How do we Verify students?
The InAcademia Service provides merchants with a quick, easy, reliable and secure way to verify academic affiliation (whether a user is a student, a member of staff or faculty), provided the student is registered with a participating eduGAIN Identity Provider.
It does this by using the student’s credentials issued by their home institution. Deploying the InAcademia Service allows students to authenticate themselves in the same way that they would to access any access-controlled institutional service.
InAcademia leverages information from the higher education federation for identity, authentication and authorisation, eduGAIN, which provides an infrastructure used by thousands of institutions to enable their students and staff to authenticate with internal and external service providers. Validation can be configured to be requested in real time, and the information is up-to-date as the identity of the user has been verified (by the academic institution). Sometimes retailers choose to join national identity federations, however, the upfront investment for joining a national identity federation to identify students, both technically as well as contractually, is comparatively high. Technical solutions, including using eduGAIN alone to access student information, would need to deal with potentially thousands of institutions, and providing services to each new institute would require separate arrangements including how to handle specific types of metadata, etc. InAcademia manages the complexity for you.
InAcademia uses the student’s identity credentials that are issued by the home institution, without forming part of the supply chain in fulfilling products or services, and performs an auxiliary service that prevents the need for students to send scans or originals of their identity documents for verification. Your student validation process will no longer rely on requesting and checking hard copies, scans or photographs of ID.
The process can be configured to trigger either during registration or checkout on a merchant's website - the merchant decides when - and the merchant is provided with an pseudonymous identifier to confirm the student’s status in real time, therefore, proving their entitlement.
When a validation request is initiated at a merchant’s website it 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 whether the response matches the requested affiliation and sends back the result to the requesting merchant.
- ‘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.
What Are The Supported Affiliation Types?
Student = Is the end-user a student at the institution?
Faculty or Staff = Is the end-user a teacher/researcher (faculty) or a worker (other than teacher/researcher, staff) at the institution?
Member = Is the end-user affiliated to 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 to choose the information it passes 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.
Authentication and attribute consumption is handled by the SAML Service Provider component of the InAcademia, which is a SAML2 SP and a member of eduGAIN. InAcademia itself is stateless; it does not cache or store the contents of the transaction in any way. Based on the requirements of the merchant, InAcademia can perform a validation using a ‘Transient‘ or ‘Persistent‘ profile.
For the transient profile no information whatsoever is provided to the merchant that can be used to build a profile of the user.
For the persistent profile a pseudonymous identifier is provided by InAcademia to the merchant, this identifier is constructed in such a way that it cannot be traced back to identifier(s) provided by the home institution. The pseudonymous identifier will however remain the same in subsequent calls (by the same merchant) to InAcademia for the same user. This is useful for ‘one per person’ type of offers, where merchants need to be able to check whether a user already benefited from a this offer before (without InAcademia divulging any personal information to the merchant). Different merchants do receive different pseudonymous identifiers for the same user, to prevent building of profiles of a user by colluding services.
After receiving the attributes, InAcademia interprets the attributes and based on that creates the required response. InAcademia can only respond with boolean values and simple claims. At no point personally identifiable attribute information, as was received by the SAML backend of InAcademia, is passed to the merchant.
Both identifiers for the requesting merchant as well as the identifier for the authenticating IdP are logged in a transaction database.