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.

InAcademia is a web service that enables the communication between e-commerce applications (either for purchase of goods and services, or for registration to access membership benefits or restricted content) and an institution's identity provider (IdP). This means that users can validate their entitlement to discounts and services in a similar way that they would to access any access-controlled institutional service. The web service provides a REST interface for clients to request a user validation using the OpenID Connect (OIDC) protocol. On the other side, InAcademia is able to communicate with the user's home institution's identity and access management systems using other protocols (primarily SAML).

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 affiliation 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 the technical nuances of 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 that complexity for you.

InAcademia performs an auxiliary service, without forming part of the supply chain in fulfilling products or services, and 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. Some merchants choose to verify users academic affiliation by requesting confirmation of access to academic email domains, however, this method does not provide any assurance of the user’s role at that institution.

The InAcademia 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 user's affiliation in real time, therefore, proving their entitlement.

When a validation request is initiated at a merchant’s website it triggers an OIDC request at the InAcademia service endpoint. Using the SAML protocol, the user is then asked by InAcademia to prove affiliation with the academic community by entering their institution-specific credentials directly into their home institution’s systems. When the institution's IdP returns the authentication response, InAcademia evaluates whether the response matches the requested affiliation to be validated and sends back the result to the requesting merchant, in a privacy preserving format.

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, and the service will construct a pseudonymised transient identifier along with a simple confirmation of the user's affiliation (using either the ePSA or ePA attributes).
  • ‘Persistent’ profile. When using this profile, InAcademia will validate the user's affiliation in the same way as described above, but the response will also contain a pseudonymous persistent identifier. Different merchants will receive different pseudonymous identifiers.

The pseudonymous identifier is identifier is constructed in such a way that it cannot be traced back by the merchant 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 subsequent to the first validation, provided that the relevant attributes are supported and released by the institution. This is useful for ‘one per person’ style offers, where merchants need to be able to check whether a user already benefited from this offer before (without InAcademia divulging any personal information to the merchant). Different merchants do receive different pseudonymous identifiers for the same user - so this prevents building of profiles of a user by colluding services. Note that the validity of the identifier depends on the institution maintaining the identifier's persistence.

The scope relating to the user’s affiliation is included in the response sent to the requesting merchant. If the user has multiple affiliations, only the scope relating to the specified affiliation to be validated is returned, and merchants may only request validation of one affiliation per OIDC request.

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?

Employee = Is the user an employee at the institution?

Member = Is the end-user affiliated to the institution (i.e. either a student, faculty, staff or employee)? Please note that in this case, InAcademia will not distinguish whether the user is a student, staff, faculty or employee.

Supported Claim Types

The response may also contain additional claims, should an institution be willing and able to provide the necessary attributes.

idp_hint assertion = This confirms that the request was validated by an individual at the institution that was subject of the request, provided that the idp_hinting function is utilised.

reuse_detection = This is intended to identify abuse of one-time only offers.

country = The country of the users’ home institution (deprecated summer 2021).

domain = The domain name of the users’ home institution (deprecated summer 2021).

In all cases (all validation flows and claims) the user is presented with a consent screen, allowing the user to decide whether it consents to the information being passed to the requesting merchant. Denying consent results to failure of the validation, is signaled to the merchant and no ID Token is provided to the merchant.

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.

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 affiliation and therefore does not carry any personal information beyond a pseudonymised identifier. 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 depends upon the Identity Providers available via eduGAIN, the pan European interfederation for Research and Education, and, in some cases, the nationally federated identity providers not announced to eduGAIN.

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. The InAcademia infrastructure is stateless.

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 is personally identifiable attribute information, as was received by the SAML backend of InAcademia, 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 for a period of 28 days before being purged; this information is distilled in order to provide a statistics log from which invoicing reports can be generated.

More detail is available here:

Skip to content