Introducing attribute release

Tim Lloyd discusses the key to patron privacy in an era of single sign-on

Although attribute release may not be a phrase you’re familiar with, it’s a critical part of the infrastructure that enables organisations to protect the privacy of their users, whether that’s library patrons, educators or researchers. It’s probably also a process you already manage in your personal life!

Every time we use a single sign-on solution like Google or Facebook to access an app on our phones, we’re allowing them to share some information about us with that application. Think of those annoying (but important) pop-up windows that ask us to agree to share information with third parties. In some cases, it’s just your name and email, and in others it may be more information, such as access to your documents or contact list.

Attributes are simply information about you that your identity solution is sharing with a third party as part of an authentication process. Attribute release is the process by which this information is shared.

So, how does this play out when we use single sign-on to access educational resources that rely on our organisational affiliation? For example, a student accessing a library resource; a researcher searching for a journal article; or an academic collaborating with colleagues to write a paper.

And, more importantly, how can organisations protect our privacy when sharing the information needed to give us access to these external resources?

If you work with electronic resources – whether as an information provider (such as a publisher) or as an information consumer (such as a library) – here’s an overview of what you need to know about single sign-on and user privacy.

First, some basics. In an educational context, single sign-on involves three parties. There’s you, the user, who wants to access an online resource. There’s the service provider, who provides that resource, such as a publisher or a research collaboration. And there’s the identity provider who authenticates your identity as someone with the right to access that resources, such as your organisation.

When you use single sign-on to access a resource, the service provider asks your organisation to confirm your right to access that resource. In turn, your organisation may ask you to enter credentials, such as a username and password. Once you’ve been successfully authenticated, your organisation will confirm back to the service provider that you’re authorised for access, and, at this point, will release one or more attributes to them. What attributes are we talking about? They come in several different flavours, depending on how much information the service provider needs to successfully deliver service.

Why do we need attributes at all? Attributes are important because they give organisations and their service providers greater control over your experience. For example:
• Access control: a resource could be limited to users who are full-time staff, preventing, say, alumni or contractors from access;
• Cost control: a resource could be limited to users with a certain role, or from a certain department; or
• Risk control: pseudonymous identifiers allow users to benefit from personalisation, without the risks associated with sharing and storing personal credentials with yet another service (and the hassle of remembering yet another username and password).

What’s recommended practice here? NISO is a member of The Coalition for Seamless Access, an important cross-industry initiative aimed at simplifying institutional access to online resources via single sign-on. They recommend the following practices for attribute release:
• By default, organisations should only share anonymous or, if necessary, pseudonymous attributes with service providers;
• Service providers should only request the least-intrusive set of attributes needed and shouldn’t retain any extra attributes received. If more information is desired from users, consent must be sought and users should have the opportunity to add/review/edit the information they share, such as via a profile page; or
• Attributes shouldn’t be used by service providers for non-access purposes without prior consent or proper legal basis, and should be deleted or anonymised when no longer needed for service access.

And what does that mean in practice? Attribute release needs to vary according to the differing needs of service providers. For example, here are four different real-world scenarios and the attributes needed to support them.

Getting this right requires co-ordination in organisations to ensure that the attributes released by internal identity systems (typically controlled by IT) reflect the needs of the users and the services they want to access (typically managed by other departments, such as the library). These conversations need to start with a common understanding of the critical role attribute release plays in resource access.

Can we make this co-ordination easier? Yes!  We all face a similar challenge in managing how we share information via social networks – it’s much easier to arrange your contacts into groups (friends, family, work etc) and to set rules on sharing at the group level, rather than manually configuring for each person. 

The Coalition for Seamless Access is similarly exploring how service providers could be grouped into categories based on their attribute requirements. This would allow organisations to automate attribute release based on a service provider’s category, rather than manually configuring attributes for each service provider.

For example, attributes to enable access to library resources are typically far more limited than those needed to support research collaboration between academics in different institutions.