SeamlessAccess intends to improve the way people from universities and colleges around the globe access content and services. To better understand the diverse situation in these institutions we have constructed two short surveys, available till March 27th 2020:

Please either fill out the survey or forward it to mailing lists, websites, or other forums followed by people working in academic libraries or IT.

Following feedback before and during the Internet2 Technology Exchange, the Seamless Access program is reviewing the permissible use of the stored Identity Provider (IdP) preference information when using some of the integration models (see our “Getting Started” page for more information about the different integration models).

What we realized is that in its current form, authorized Service Providers (SPs) using the advanced integration model may be able to access stored IdP choices before a user logs into that SP’s service. When a website authorized to use SeamlessAccess connects their Federated Identity Management (FIM) service, the website can see the user’s previous choice of IdP before any user authentication occurs. This design choice was originally made to enable full flexibility of the user interface for advanced integrators, for example, to display the preferred IdP in the interface. Further, integrators using the limited and standard integration models are unable to access stored IdP choices.

We now understand that the current situation has some privacy implications that take the service beyond what SeamlessAccess has been promising. For example, a SeamlessAccess-authorized SP could potentially collect information about exactly which IdPs are preferred by the user (which is often correlated to a person’s affiliation) without the user being aware. While the persisted choice of IdP is not considered personally identifiable information (see the WAYF Cloud and P3W Security & Privacy Recommendations from RA21 for more detail) the exposure of any information outside of what matches a more traditional authentication flow runs counter to the principles of SeamlessAccess.

The SeamlessAccess Governance Committee is currently evaluating several options to remediate this unintended possibility, including, but not limited to:

  • Changes to the advanced integration API which make it impossible to access the stored IdP choices while still allowing the UI customization and integration with local discovery services for which this model was originally intended.
  • A UI mechanism to allow users to grant permission to SPs to access their stored IdP preference information.
  • Clear prohibition in the Terms of Use of SeamlessAccess of utilization of stored preference information in any way that is not intended.

In order to become an authorized SP for the advanced integration model using our production service, the SP has to follow a process that includes a review of their proposed integration with SeamlessAccess. The SeamlessAccess governance committee is currently working with appropriate legal counsel to develop a strong Terms of Service and Privacy Statements that will be part of authorizing any new SP. A link to the onboarding process and appropriate policies will be made available on the SeamlessAccess website as soon as they are complete.

As we have more information and documentation on how to integrate with SeamlessAccess, we will let you know.

This guide is for non-technical people who want to understand how attribute release enables secure and privacy-preserving access to online library resources using federated identity management. If you first want to read up on what federated identity management is, you can find a basic introduction here.

What are attributes?

Attributes contain information about an end user that are passed to a publisher or service provider after authentication. Think of a name, email address etc.

An end user working or studying in the Research & Education (R&E) sector often has a user account with their institution. Their institution is the ‘identity provider’ of the user, commonly abbreviated as IdP. During an online authentication workflow, the IdP can often provide additional attributes about the user1 to the organization initiating the process (also known as the Service Provider or SP).

Why are attributes important?

Attributes can be used to transfer information about the end user from the IdP to the service a user wants to access. For example, attributes are commonly used for:

Use Example
Access control e.g., only allow users who are full-time staff
Cost control e.g., only allow users with a certain role, or from a certain department
Risk control e.g., avoid the need for (i) users to separately register a username/ password and (ii) 3rd parties to store credentials
Convenience e.g., save search results for subsequent access. And avoid the user having to provide duplicative information to the SP that their IdP already holds

Attributes and attribute release can be very helpful in ‘doing business’ and enabling users to do their work. To protect user privacy and comply with data protection legislation, it is important to limit the release of personal data.

Types and examples of attributes

These attributes can be classified according to the amount of information they reveal to the SP about the user:

Anonymous identifier:

  • Some services want to receive an identifier, for example because they technically need one. The IdP can generate identifiers2 that are unique for every visit and SP
  • Real identity unknown (anonymous)
  • Does not allow for personalization

Pseudonymous identifier

  • IdP-generated identifier3 unique per person/SP-combination
  • Real identity unknown by the SP (pseudonymous)
  • Personalization possible


  • Home organization, Entitlements, Role, Department, Location, etc.4


  • Name, email address

How does attribute release work?

In general, the flow goes as follows: a user lands on a web page of a service (an SP), often via a search engine like Google, and clicks a login button that brings them to their IdP, while the SP specifies what attributes it would like to receive. The user signs in at their IdP. After successful authentication, the IdP redirects the user back to the service, while providing zero or more attributes. Graphically:

Attribute Release Workflow Diagram

The IdP is always in control of what attributes are released to an individual SP, and has a responsibility to limit attribute release and protect the users privacy. Depending on the national legislation, IdP’s should check to see whether they need a contract between the IdP and SP to release personal information that defines, amongst other things, what other attributes are necessary and how the privacy of the user is protected.

RA21 and recommendations

RA21 has adopted the GÉANT Data Protection Code of Conduct (DPCoCo), an R&E-led initiative that defines behavioural rules for SPs that want to receive user attributes from IdPs. The DPCoCo sets the stage for compliance with the principles behind the EU General Data Protection Regulation (GDPR).

RA21 recommends:

  • For SP’s:

    • Only request the least intrusive set of attributes; what you need, not what you want.
    • If the service thinks it has good reasons to request more information from the user, the service should provide a profile page in the service, so the user can, on an individual basis, enter more information (like a name, an email address etc).
    • Do not retain any extra attributes that you receive.
    • Do not use attributes for non-access purposes without prior consent or proper legal basis.
    • Delete or anonymize all attributes when no longer needed for service access.
  • For IdP’s:

    • Limit attribute exchange during authentication.
    • People from IT and libraries to start working together, to discuss attribute release, minimizing attribute release, and informing users about what data is exchanged, why and on what grounds
  • For both:

    • Only share anonymous or, if necessary, pseudonymous attributes.
    • Make sure there is a proper lawful basis for exchanging attributes.

Here are some example scenarios showing how attribute release can enable different levels of personalization for the user:

Scenario Attributes
Users access a website or resource that is access controlled by provides full-text articles with no options for personalization Anonymous attributes
Users access a website that provides personalised get content recommendations in its UI based on prior visits/history Pseudonymous ID
Faculty have the ability to purchase ebooks using library funds Pseudonymous ID, User role
Clinicians receive email confirmation of Continuing Education credits received Pseudonymous ID, User email address (with user consent)

  1. Technically, an organization can be (one of many) attribute providers for a user, without also being their identity provider. Typically, an R&E institution acts as both identity provider as well as the main (or only) attribute provider. [return]
  2. As an example: in SAML the ‘NameID’ attribute can be used to communicate a transient id. The Shibboleth wiki has a nice overview of identifiers. [return]
  3. As an example: in SAML the ‘Pairwise Subject Identifier’ is the current state of the art identifier (while in older configurations ‘eduPersonTargetedID’ and SAML 2.0 ‘persistent NameID’ is still being used). [return]
  4. Not all federations release the same set of attributes. But there is a core set which most can supply. [return]

Taking the findings of the RA21 initiative to the next level, intends to support a streamlined federated authentication experience when using scholarly collaboration tools, information resources, and shared research infrastructure. The service will promote digital authentication leveraging an existing single-sign-on infrastructure through one’s home institution, while maintaining an environment that protects personal data and privacy. The service aims to enable simple, trusted use of scholarly resources and services anytime, anywhere, and on any device.

As part of our efforts to encourage organizations that support federated authentication, including publishers and platform providers, we are hosting a hackathon for developers. A hackathon is a hands-on developers meeting that offers individuals an opportunity to sit at a table with the architect or lead developer of a code base and get hands-on support in implementing the open-source software behind A hackathon is not a tutorial, nor is it a presentation or conference session, and it is not suitable for non-developers.

Your organization is invited and encouraged to send members of your development team to the event to engage in understanding and developing code (bug fixes, feature enhancements, etc) against either the metadata query system and/or the code behind ( This is a critical time in setting the direction of the service, and understanding how publishers and platform providers expect to integrate with the service is key.

There will be a second T&I Hackathon in the US on 10-11 December 2019, concurrent with the Internet2 Technology Exchange 2019 conference in New Orleans. The service will be at a different point in its development, and the questions and issues to be discussed are likely to be quite different at the second hackathon.

Participants in the hackathon will need to have the ability to access a test/dev environment for where they can install and test integrations with We will provide the Internet connections, the power, and the platform source code.

Registration for the hackathon is part of the overall NORDUnet Technical Workshop. The NORDUnet Technical Workshop (NTW) is is held every two years in Copenhagen. The main event (24-26 September 2019) features a series of workshops on subjects related to research and education networks, including a full day of trust & identity workshops. The NTW brings together 150-200 practitioners from research and education networking communities in the Nordic countries and beyond. The event is held a 5-minute metro ride from Copenhagen airport, 10 minutes from central Copenhagen.