The 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 Services.

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 Service, InAcademia can perform a validation using a ‘Transient‘ or ‘Persistent‘ profile.

For the transient profile no information whatsoever is provided to the Service that can be used to build a profile of the user.

For the persistent profile a pseudonymous identifier is provided by InAcademia to the Service, 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 Service) to InAcademia for the same user. This is useful for ‘one per person’ type of offers, where Services need to be able to check whether a user already benefited from a this offer before (without InAcademia divulging any personal information to the Service). Different Services 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 Service.

Both identifiers for the requesting SP as well as the identifier for the authenticating IdP are logged in a transaction database.