GetFTR: dataflows and user privacy

Institution selection – illustration of how a user may enter their affiliation on the website of a service integrating with GetFTR. This enables the integrator to query the GetFTR system to see if the user is entitled, via their institution, to a specific piece of content

Another commonly used identifier is the user’s IP address. Support for IP-based authentication was added to GetFTR after the initial launch upon request from users and in consultation with pilot participants and the GetFTR advisory board.

This means that integrators can also share user’s IP addresses with GetFTR, although this is optional. Those that choose to share user’s IP addresses with GetFTR and participating publishers, have to notify users via their privacy policy ahead of doing so. GetFTR and publishers who receive IP address information from GetFTR are only allowed to use this for the purposes of checking entitlements.

Note: Most Discovery Services implement deferred authentication, which means the user authenticates after they have clicked on a GetFTR link to access content on a publisher or aggregator site (unless they are already authenticated). Some Discovery Services chose to handle authentication themselves. Once the user is authenticated, GetFTR links provide one-click access to content across all participating publisher and aggregator platforms.

Step 2: GetFTR Processing

When GetFTR receives an entitlement request, it checks the entitlement status with the relevant publisher in real-time. To enable this, GetFTR uses Crossref metadata to determine which publisher is associated with a particular piece of content (identified by DOI), and then routes the entitlement request to the correct publisher. Only the relevant publisher will receive the entitlement request; this data is not shared with other publishers or organisations.

Step 3: Publisher Entitlement Responses

For every document, the publisher returns a corresponding “entitlement resource” to GetFTR, which is a piece of information that establishes the level of entitlement (e.g. yes, no); access type (e.g. open, free, paid); document type (e.g. version of record or alternative version); content type (e.g. html, pdf) and a link to the actual resource if appropriate. GetFTR, in turn, sends this entitlement resource on to the integrator where it can be used to signal to the user if they will have access to the content.

Step 4: Integrator display entitlement

Having received the entitlement resource, the integrator now knows which content items the user has access to, and uses that information to display the appropriate GetFTR indicators. In addition, if the user is entitled to access the content, the publisher sends a ‘smart link’ that allows the user to bypass repetitive authentication steps.

What does GetFTR not do?

GetFTR does not store information about its users, which links the user clicks on the integrator’s site, or which articles they view on a publisher’s platform

GetFTR also does not control or mediate access in any way. Once a user clicks on a link from an integrator, they are directed to the publisher’s platform where they still need to be authenticated and authorized. For users using SAML based-access (federated access), GetFTR does streamline the access user journey by providing ‘smart links’ (which are in essence so-called WAYFless URLs) to the integrator. Such a smart link contains the user’s institutional affiliation, but no other user data, thereby effectively passing that information along from an integrator service to a  publisher. The publisher, in turn, can use this information to direct the user to their institution’s login page or directly to the content if they are  already authenticated.

As always we welcome further discussion should you have thoughts, comments or want to know more information. For this please contact Dianne Dianne Benham (GetFTR Product) Dianne@getfulltextresearch.com