Analysis and news
Introducing attribute release Tim Lloyd discusses the key to patron privacy in an era of single sign-on
as someone with the right to access that resources, such as your organisation. When you use single sign-on to
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
16 Research Information November 2019/January 2020
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
Anonymous identifier
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 are important because they give
organisations and their service providers greater control over your experience”
Suitable when an individual identity is not needed, eg ‘a3c5d4e99’ • identifier changes for every visit (session) and service provider, so returning users cannot be recognised
• real identity unknown (anonymous) • no personalisation
Pseudonymous identifier
Suitable when the service provider needs to recognise a returning user (but doesn’t need their identity). Same format as above. • identifier unique for every person and service provider, so returning users can be recognised by the same service provider
• real identity unknown (pseudonymous) • enables personalisation
Organisational information
Personal information
Table 1 @researchinfo |
www.researchinformation.info
Used to transfer details about a user’s organisation, such as organisation name, entitlements, role, department etc
Used to transfer details about a user, such as name and email address
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32
