...
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.
Everything happens either during registration or checkout on your website. 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.
...
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.
...